[rsbac] Trusted Path Execution and scripts

[tazok]

2006/7/20, Jens Kasten <jens at igraltist.dyndns.org>:
>
> rsbac has more also models, than what i use.
> only to  see if i understand it properly.
> a) every binary or file has a rc-type.
> b) the user e.g on /home/user1 has rc-type 1000
> c) the user1 has a rc-role 1000
> d) every service wich is running has his owne rc-role
>
> than the .bashrc has a different rc-type  e.g 10001
> every think the user1 need to login has his owne rc-type so he can login.
> than the rc-role 1000 has no execute right on rc-type 1000.
> how he would do something bad.
> the rc-role 1000 has also not access to the rc-type on /usr/bin/perl.
> so mayby he can write in his rc-type 1000 directory some bad thinks,
> but this rc-role 1000 can  do nothing. how will he eable to call the perl?
> for me unpossible.  remember on all main files or directory has to stay
> rc-types, so that no default is accepted.
> so every think under the rc-type 1000 directory is under controll from the
> rsbac and has no default.
>
>
> _______________________________________________
> rsbac mailing list
> rsbac at rsbac.org
> http://www.rsbac.org/mailman/listinfo/rsbac
>


Yes, all file all directory has his own type, and each user has his own
role.The background (and the causes because it can't be solved) of the
problem is this:

The Home directory (under the type made to this user, who is under his own
role), must have writting permissions to him. The reason is clear, to permit
them make their job. When the user logs in the system, bash makes a
read_open call to get the data from the .bashrc or the bash_profile for
example. If a user runs one program it reads his configuration file from
their own .myprogram in the home directory or from /etc if it doesn't exist.
If the last condition is true (doesn't exist) it creates one (is the
common).
However the read_open calls and read_write_open calls are everywhere.

Making all rc files of the user another type don't solves nothing because
the problem is not to which type they can access if not that all users needs
writing permissions in their home directory and needs the read_open and
read_write_open (and you have to grant those privileges to the type you
assigned to them (to reed a simple mail you need read_open, the same
privilege needed to launch a script)). This makes that  they could write an
untrusted script and run it.

How you can see the execute privilege is not the problem (it has been
restricted to all types no "executables"). The problem is that the execute
privilege is not necessary to launch one script, only the read_open is
needed if launched as "bash path_to_my_script.sh". And because from one side
this privilege is commonly needed by all software running under bash (or
others shells) and the same bash needs it to read their own config files it
can't be solved (this is what I'm beginning to think).

The problem of the perl and python has been already solved making them a
force role (or initial role probably, I must look this better), and grant
the read_only privilege only to the trusted_scripts rc_type for this role
(so one perl script written by a user couldn't be launched because the
forced_role of perl hasn't read_open privileges to it ;) ).

 I haven't assigned the binaries perl and python to one different type than
executables and I haven't forbidden the execute privileges to the users
because they need them to work (they will use them but the only scripts they
could run under perl and python will be which I say them (the
trusted_scripts type).