[rsbac] ssh rc-role

[Amon Ott]

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 
runs
> > with the initial role and has minimal rights, or tries to setuid, 
and
> > 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 
in
> any case if (for example) one stack overflow ocurrs within because 
it
> was granted the capability to change to the secoff ID (maybe through
> one ret2libc attack invoking the setuid call¿?). If it's the case, 
by
> 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 
accound.

> 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 
only
> 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.

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