[rsbac] Trusted Path Execution and scripts

tazok tazok.id0 at gmail.com
Thu Jul 20 01:46:59 CEST 2006


   <how can a local service connect from the internet?

Well, with local service I want mean a service launched by a local user, not
one that uses the loopback device.

<if a service offer something he has to be in a jail and in a rc-role
> normaly.
> <ore use the attacker an account from a already existing user?.


Local users couldn't need to be trusted, the example of before was to
explain me better.

<but what can an user do if on every binary in /bin /sbin /usr/bin etc.  and
> on
> <every directory put an rc-type. than an user can not even do an echo if
> is
> <not allow. so he can not use make or gcc anyway is it installed. i think
> the
> <general settings are only that the system are running. when it is running
> the
> <most can be modified.


They can use an trusted binary (one resident in /usr/bin /sbin or /bin and
as type executable for example that couldn't be modify by any way) to launch
an untrusted script as for example: bash
/home/$user/untrustedscripttocrushyourkernel.sh. This action doesn't need
execute privileges, only the read_open one.

    <it is no reason there to let a user assosiatet with the general_role
rights.

> <every user or similarly groups have to get its owne rc-role and his owne
> <rc-type on his home directory.


I know, it was only an example. The problem will exists forever because
users have writting permissions to their home directory for example, for
this reason they can write one exploit based on a perl script and be
launched as I put you before, remember that one kernel bug could give high
privileges o causes the system to hang (in ring 0 all is possible, and as
far as I know rsbac can't protect this)

    <this prevent to execute the mostly, because

> <simply not allow the users rc-role on the rc-type on his home directory
> to
> <execute or what is needed.
> <so when he get an remote access via ssh this role has no right to the
> perl, he
> <can not use it, he need even rigths to do an simply ls.


As I told you before, there is not problem with binaries themselves (as ls),
the problem comes with scripts. Make the assumption that the users will get
access to the executables type to do their work, they can't modify
(trojaning) them (even root) by the simply reason that this action is not
permited, no others binaries could be launch (by revoking  the map_exec and
the execute privileges for all types no executables), The problem is not
this kind of use, in the sense that this binaries are trusted and will do
which we wait they must do, the problem are the miss use of users that use
them to launch untrusted perl scripts for example.

To perl and python, making them an unique forced role and revoking all
execute and read_open privileges to all types not "trusted_scripts" would be
enough, but in the case of bash you can't do it, first because you can't
forgive the access to it to anyone because they couldn't even logging into
the system, you can't forgive the read_open privilege too because it reads
for the .bashrc file for example, however this users could write scripts and
launch them without control and this is the question that I can't find one
solution.


More information about the rsbac mailing list