[rsbac] sshd problems

Sven Seeland sven.seeland at gmx.de
Wed Apr 11 18:50:17 CEST 2007


I tried your patch and I'm afraid to say that it didn't work. However, I think I 
know why. Here's something to think about:

[beginning of transcript]

secoff at asgard ~ $ cat /proc/rsbac-info/rmsg
<6>0000001255|rsbac_adf_request(): request CHANGE_OWNER, pid 9714, ppid 	 
9711, prog_name sshd, prog_file /usr/sbin/sshd, uid 0, audit uid 400, remote ip 
192.168.11.3, target_type PROCESS, tid 9714, attr owner, value 400, result 
NOT_GRANTED (Softmode) by AUTH
<6>0000001256|rsbac_adf_request(): request CHANGE_OWNER, pid 9714, ppid 9711, 
prog_name sshd, prog_file /usr/sbin/sshd, uid 400, audit uid 400, remote ip 
192.168.11.3, target_type PROCESS, tid 9714, attr owner, value 0, result 
NOT_GRANTED (Softmode) by AUTH

secoff at asgard ~ $ su -
root's RSBAC password:
asgard ~ # ps -Al | grep 9714
4 S   400  9714  9711  0  75   0 -  2020 wait   pts/4    00:00:00 bash
4 S     0  9723  9714  0  75   0 -  1585 wait   pts/4    00:00:00 su
asgard ~ # ps -Al | grep 9711
4 S     0  9711  9411  0  75   0 -  2752 -      ?        00:00:00 sshd
4 S   400  9714  9711  0  75   0 -  2020 wait   pts/4    00:00:00 bash

[end of transcript]

Notice how the process that is denied CHANGE_OWNER is actually a bash process? 
Doesn't make much sense to me since the RSBAC log clearly states that it's sshd. 
Or doesn't it? The parent process is sshd but since the bash process isn't 
allowed to setuid at all, it doesn't really care much for the parent process 
inheriting the last_auth (which it probably doesn't, since it's not a fork). And 
what's that su process owned by root doing there anyways? I didn't do anything 
after I used ssh to log in as secoff. Oh yeah, all of this was done with 
Privilege Seperation turned off.

Well, this really is a though nut to crack (or something like that). I really 
appreciate your efforts, Amon! I've never seen anything like that in other open 
source projects (or closed source projects either, for that matter).

Greetings,

Sven



Amon Ott schrieb:
> On Wednesday 11 April 2007 10:39, Sven Seeland wrote:
>> I turned off privilege seperation and it didn't help. I can't say
>> for sure but it seems like the (priviliged) parent process is now
>> doing the communication and after authentication spawns a process
>> for setuid. So the authentication and the setuid are still in
>> different processes. I'm considering turning privilige seperation
>> back on again and imposing only very, very loose restrictions on it
>> with RSBAC, trusting it to be a secure program... I really don't
> 
> Please try the attached patch to get last_auth inherited to the child 
> process. It is already in svn. Maybe it solves the problem.
> 
>> Maybe I'll restrict SSHD to setuid only to a range of unpriviliged
>> accounts (for up- and downloading) and one login account, which is
>> then in turn privileged to setuid to secoff. Not great but it's a
>> start. Any better ideas?
> 
> We are using SSH keys instead of passwords. root and secoff logins are 
> only allowed for one hour, after another admin enabled them. It is 
> solved with a ttl limited AUTH cap.
> 
> Amon.


More information about the rsbac mailing list