[rsbac] Trusted Path Execution and scripts

[Jens Kasten]

> Imagine this situation: One remote user uses a vulnerability against a
> local and unprivilege daemon and get access as a normal user to the system.
> His role then would be general_role for example (the default). Then he
> finds one kernel bug and try to use it, imagine that ssp and PaX fails to
> stop it. To trying it, he needs or write the exploit and use it (or
> download it to the system). With the trusted path execution the execution
> of untrusted binaries are solved (only can be executed binaries in /sbin
> /bin /usr/bin and so on, no one downloaded or compiled by him could be),
> the problem comes when he uses one perl script for example to do it.  As
> Amon Ott said in other thread it can be necessary or the execute and the
> read_open privilege (if used as a normal binary) or only the read_open
> privilege if we tell perl to interpret it.
>
> Which I want to stop is to launch this untrusted scripts that only use the
> read_open privilege avoiding perl for example to interpreting them, I think
> doing it by a role_force way is a proper solution to it (in perl and python
> cases). The problem comes with bash.
>
> I am not sure if an "exploit" could be written with a bash script, I
> imagine that the person which could do this has to be a genious between
> others things. I want to make sure of the imposibility to do it by this
> way. Thanks for all and sorry if some of you didn't understand the mail.

how can a local service connect from the internet?
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?
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.
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. 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.