[rsbac] sshd problems

[Amon Ott]

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