[rsbac] sshd problems

[Sven Seeland]

I'm sorry if any of this sounds dumb but I'm really new to all this linux/security stuff. Let me see if I got this right...

The euid is used to check for priviliges and the fsuid is used to check for filesystem access. So with euid and fsuid set to root, the program can  do whatever it wants, within the bounds of its RSBAC role.

However, since I don't allow it to change the ruid, the program won't change its role when switching to root even though I have RC Force role set to up_mixed. Only after the authentification (which can only happen with a correct password since I'm using in-kernel UM, right?) does it change the ruid and therefore the role to whatever the role of the authenticated user is, right?

I can't try any of this right now since I don't have access to the server right now (it's not online yet).

One thing that keeps me wondering though is the following:
I once set AUTH May Setuid to yes (unrestricted) to try if it worked that way. The program changed to 22, then to root and then failed to authenticate because it's role remained 0 (General User). All I got was a PAM notice that the user couldn't be authenticated and RSBAC log told me that an AUTHENTICATE request was blocked for sshd run by uid 0 and rc_role 0. Why didn't it change to System_Admin role when it switched to root? I had RC Force Role set to up_mixed and no restrictions on the AUTH capabilities...

Thanks a lot for the help,
Sven


-------- Original-Nachricht --------
Datum: Wed, 4 Apr 2007 10:16:16 +0200
Von: Amon Ott <ao at rsbac.org>
An: RSBAC Discussion and Announcements <rsbac at rsbac.org>
Betreff: Re: [rsbac] sshd problems

> On Wednesday 04 April 2007 10:04, Sven Seeland wrote:
> > So you are saying I should grant the initial sshd process the right
> > to setuid to root and to authenticate users? Isn't that a huge risk
> > in case sshd is hacked, as it has been before? I'm thinking whether
> > it might be safer to work with a fake root and a min cap that
> > allows setuid btu that doesn't help that much because the attacker
> > would then still have the right to setuid to root.
> 
> You only allow setting the euid and fsuid to root, not the real uid. 
> So this root process runs with the SSHD Initial role and has only the 
> rights you want it to. Additionally, you can remove all unnecessary 
> capabilities with a CAP max_caps setting.
> 
> Also, during network conversation the process runs as user 22. You can 
> further reduce its rights, if you assing yet another role as def_role 
> to that user.
> 
> If you know that you will never need administrative rights over ssh, 
> you can also run sshd in a jail. Then whatever RC roles the users 
> have, they will always be inside this jail with limited rights, if 
> they came through ssh.
> 
> > And to answer your questions: yes, the sshd user 22 has role 0 and
> > I'm trying to login as secoff. I already have debug_adf_rc enabled,
> > that's how I know that the process that is trying to authenticate
> > has the role 0.
> 
> Oh yes, right.
> 
> Amon.
> -- 
> http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
> _______________________________________________
> rsbac mailing list
> rsbac at rsbac.org
> http://www.rsbac.org/mailman/listinfo/rsbac

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail