[rsbac] sshd problems

[Sven Seeland]

Hi Amon!

First of all, thanks for the quick answer.

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.

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.

Regards,
Sven

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

> On Tuesday 03 April 2007 19:07, Sven Seeland wrote:
> > I have configured /etc/sbin/sshd in the following way:
> > RC Force Role: mixed inherit proc/user
> > RC Initial Role: 0 (General User)
> > AUTH May Setuid: 3 (Last authenticated user and all groups)
> > As well as auth capabilities to change to user 22 and group 22
> > (which is the native user and group for ssh)
> 
> This means that sshd starts with role 0, but role is changed with the 
> first setuid. Authentication is thus done before setuid with role 0.
> 
> As first step, please enable RC debugging with rsbac_debug_adf_rc 
> kernel parameter or at runtime with
> echo "debug_adf_rc 1 > /proc/rsbac-info/debug"
> It will show you all RC roles and types involved.
> 
> > When I try to log in with softmode enabled, sshd first tries to
> > assume user and group 22, which it is granted since I allowed it.
> 
> Does the ssh privilege separation user 22 have the same role 0?
> 
> > It then tries to CHANGE_OWNER, CHANGE_DAC_EFF_OWNER and
> > CHANGE_DAC_FS_OWNER to 0 (root) once and then tries to
> > CHANGE_DAC_EFF_OWNER and CHANGE_DAC_FS_OWNER to 400 (secoff) twice.
> > None of this is granted but since we're in softmode, the program is
> > not bothered by it. After that, the user can enter his password and
> > username and is logged in.
> 
> I suppose that you try to login as secoff. sshd privilege separation 
> means that the process doing the conversation runs as user 22/ssh and 
> then has to switch back to root to setuid to the final user. You will 
> have to grant CHANGE_DAC_FS_OWNER and CHANGE_DAC_EFF_OWNER to 0, 
> otherwise sshd cannot work. CHANGE_OWNER is not necessary, although 
> it will still be tried.
> 
> > If I disable softmode, sshd fails after RSBAC disallows the chown
> > to root. The user doesn't get to enter username or password and is
> > instead confronted with the message "Connection closed by
> > 192.168.11.2" as the only output.
> 
> sshd will cut the connection, if it cannot set its euid (EFF_OWNER).
> 
> > Strange thing. If I allow setuid to any user, I can enter my
> > username and password but sshd can't authenticate them (I'm using
> > UM) because for some strange reason it's still rc_role 0 (General
> > User) even though it's uid 0 (root) which has rc_def_role 2 (System
> > Admin), which is in turn allowed to authenticate any user.
> > Therefore all I get is "pam_rsbac.so: User not authenticated" and
> > another try to enter my password.
> 
> Again: Your initial role 0 means that the sshd process doing the 
> authentication (remember: two sshd processes involved!) tries to 
> authenticate with role 0, which by default has no AUTHENTICATE right 
> on the user type. You should copy role 0 to some other number (use 
> rc_copy_role or rsbac_rc_role_menu), rename the new role e.g. 
> to "SSHD Initial", give it rights to authenticate and assign the role 
> as initial role to sshd.
> 
> You should consider assigning the same role as default role to the ssh 
> user, so that the other process doing the conversation has the same 
> role. It makes life a bit easier.
> 
> > Anyways, I hope that this is a rather complete description of the
> > problem. This is starting to drive me mad. I love the concept
> > behind RSBAC but I have to say that it is really a pain to set up.
> 
> sshd is a difficult beast because of its privilege separation scheme. 
> RC debug messages can help a lot here.
> 
> 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