[rsbac] sshd problems

Sven Seeland sven.seeland at gmx.de
Tue Apr 10 10:19:27 CEST 2007


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.

By the way, when I try the whole thing in softmode it obviously succeeds but the 
shell process (in this case 30914) tries to change back to uid 0 right after it 
changed to the login uid.

Any ideas? I'm really sorry that this is taking so long...

Thanks a lot for the help,
Sven



Amon Ott schrieb:
> On Monday 09 April 2007 20:58, Sven Seeland wrote:
>> I'm sorry for being so slow but I still can't get it right. I made
>> a copy of the General User role and called it SSHD Inital. I
>> granted this role the additional rights (AUTHENTICATE, SEARCH,
>> CHOWN, GET_STATUS_DATA) for SSHD to function properly. I set up
>> SSHD itself with AUTH May Setuid to up_mixed. I allowed it to chown
>> and chgrp to 22 and 0.
> 
> This sounds correct.
> 
>> But still, I have to explicitly allow it to 
>> chown to 400 (secoff) when I'm trying to login as secoff,  even
>> though secoff is authenticated! What am I doing wrong here?
>>
>> The thing is: sshd is trying to CHANGE_DAC_EFF_OWNER to 400 before
>> I can even enter a password. If it can't to this, it closes the
>> connection. But this means that I have to either allow setuid for
>> all IDs, which is something I don't want to do, or I have to allow
>> it to setuid to all user ids that are allowed to login via ssh,
>> which is something I don't want to do either since those may be a
>> few and they may change rather frequently. So what shall I do?
> 
> Given the way sshd works, there is not much else you can do but grant 
> CHANGE_DAC_EFF_OWNER to all uids (seteuid) that are supposed to 
> login. For me, the important thing is to deny CHANGE_OWNER without 
> authentication - setting the real uid (setuid) is what gives you 
> RSBAC rights. Then the sshd process still runs with the initial role, 
> so you can easily deny access to home dirs etc.
> 
> Amon.


More information about the rsbac mailing list