[rsbac] sshd problems

[Amon Ott]

On Tuesday 10 April 2007 10:19, Sven Seeland wrote:
> Okay, this is starting to feel embarrasing...
>
> I set the CHANGE_DAC_EFF_OWNER and CHANGE_DAC_FS_OWNER to the range
> 0:65534 in order to allow any and all uids (I will narrow that down
> later on). Now the communication works. I don't get any RSBAC
> errors until the parent process wants to spawn the final shell
> process. This is what I get (non-softmode):
>
>
> <6>0000004541|rsbac_adf_request(): request CHANGE_OWNER, pid 30911,
> ppid 30910, prog_name sshd, prog_file /usr/sbin/sshd, uid 22, audit
> uid 400, remote ip 192.168.11.3, target_type PROCESS, tid 30911,
> attr owner, value 0, result NOT_GRANTED by AUTH
> <6>0000004542|rsbac_adf_request(): request CHANGE_OWNER, pid 30914,
> ppid 30910, prog_name sshd, prog_file /usr/sbin/sshd, uid 0, audit
> uid 400, remote ip 192.168.11.3, target_type PROCESS, tid 30914,
> attr owner, value 400, result NOT_GRANTED by AUTH
>
> pid 30910 is obviously the parent process. 30911 is the process
> doing the communication. 30914 is apparently the process that is
> trying to actually spawn (or become?) the shell. Since this is
> NOT_GRANTED by AUTH the problem should lie with /usr/sbin/sshd (the
> file) and not SSHD_Inital (the role), I believe.

Only last night I realized that it is not the process doing the 
authentication which tries to setuid in the end. Instead, sshd 
creates one child process to do authentication and a new child 
process for setuid. So it cannot work this way.

Blame sshd Privilege Separation scheme for this...

You might consider turning that scheme off with
UsePrivilegeSeparation no
in sshd_config.

I will think about a secure solution to this problem - obviously we 
cannot set last_auth for every parent process, too, so that other 
children can get it inherited. During my tests, I added inheritance 
to child processes, so in other cases we might have some benefit.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22