[rsbac] ssh rc-role

Amon Ott ao at rsbac.org
Thu Aug 24 17:17:48 CEST 2006

On Donnerstag 24 August 2006 17:05, tazok wrote:
> 2006/8/24, Amon Ott <ao at rsbac.org>:
> > If e.g. sshd gets hacked like it has been before, it either still 
> > with the initial role and has minimal rights, or tries to setuid, 
> > that is restricted through AUTH (and optionally RC, ACL in RSBAC
> > 1.3). So the damage can be minimalized.
> But, it means that each process with the capability to change to the
> secoff's uid granted by the AUTH module (as for example /bin/login)
> could change to the secoff account without restrictions...So, the
> restrictions imposed to the login initial role would be inefficient 
> any case if (for example) one stack overflow ocurrs within because 
> was granted the capability to change to the secoff ID (maybe through
> one ret2libc attack invoking the setuid call¿?). If it's the case, 
> this way, there is no posibility of defense by our side is it¿?.

If you use passwords for ssh connection, e.g. also use RSBAC User 
Management and only allow setuid to authenticated uids.

If not, allow sshd to setuid to root and secoff only for a limited 
time with an AUTH cap ttl. This cap can e.g. be set by another 

> Even more, granting the setuid to secoff account to the sshd daemon
> would be a great risk even with a greatly restricted sshd initial
> role... Hmm... I didn't think about this before (until now I have 
> permitted access to secoff account locally by the login way, but I
> think it is a great danger).

If you are sure you will never need to administrate through ssh, you 
can run sshd in a jail.

In a more detailed setup, your secoff uid is never available with ssh, 
only other users with limited admin rights. The RC separation of duty 
scheme with administrated roles and special access rights etc. allows 
to split the admin tasks a lot.

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

More information about the rsbac mailing list