[gentoo-hardened] Help with su

[gentoo-hardened] Help with su

[Stan Sander]

[-- Attachment #1: Type: text/plain, Size: 4583 bytes --]

One of the more important things that is currently broken on my system
when I switch on enforcing mode for SELinux is the su command.  Mostly
likely I've overlooked something so am asking here first before filing a
bug on it.  I did a search or two on google, but didn't find anything
that looked really useful (or current).  Here are some details.  I'll
start with the output from the terminal window:

siren /home/stan $su
Password:
Would you like to enter a security context? [N] 
su: Authentication failure

Here are the lines from my syslog:

Nov 25 19:23:58 siren su[3016]: Successful su for root by stan
Nov 25 19:23:58 siren su[3016]: + /dev/pts/1 stan:root
Nov 25 19:23:58 siren kernel: type=1400 audit(1322274238.237:826): avc: 
denied  { search } for  pid=3016 comm="su" name="root" dev=sda1
ino=4290561 scontext=stan:staff_r:staff_su_t
tcontext=root:object_r:user_home_dir_t tclass=dir
Nov 25 19:23:58 siren kernel: type=1400 audit(1322274238.240:827): avc: 
denied  { compute_user } for  pid=3016 comm="su"
scontext=stan:staff_r:staff_su_t tcontext=system_u:object_r:security_t
tclass=security
Nov 25 19:24:00 siren su[3016]: pam_selinux(su:session): Unable to get
valid context for root
Nov 25 19:24:00 siren pam_ssh[3016]: can't write to /root/.ssh/agent-siren
Nov 25 19:24:00 siren kernel: type=1400 audit(1322274240.440:828): avc: 
denied  { search } for  pid=3016 comm="su" name="root" dev=sda1
ino=4290561 scontext=stan:staff_r:staff_su_t
tcontext=root:object_r:user_home_dir_t tclass=dir
Nov 25 19:24:00 siren kernel: type=1400 audit(1322274240.440:829): avc: 
denied  { search } for  pid=3016 comm="su" name="root" dev=sda1
ino=4290561 scontext=stan:staff_r:staff_su_t
tcontext=root:object_r:user_home_dir_t tclass=dir
Nov 25 19:24:00 siren su[3016]: pam_unix(su:session): session opened for
user root by (uid=500)
Nov 25 19:24:00 siren su[3016]: pam_open_session: Authentication failure

Here is the /etc/pam.d/su file:

#%PAM-1.0

auth       sufficient   pam_rootok.so

# If you want to restrict users begin allowed to su even more,
# create /etc/security/suauth.allow (or to that matter) that is only
# writable by root, and add users that are allowed to su to that
# file, one per line.
#auth       required     pam_listfile.so item=ruser sense=allow
onerr=fail file=/etc/security/suauth.allow

# Uncomment this to allow users in the wheel group to su without
# entering a passwd.
#auth       sufficient   pam_wheel.so use_uid trust

# Alternatively to above, you can implement a list of users that do
# not need to supply a passwd with a list.
#auth       sufficient   pam_listfile.so item=ruser sense=allow
onerr=fail file=/etc/security/suauth.nopass

# Comment this to allow any user, even those not in the 'wheel'
# group to su
auth       required     pam_wheel.so use_uid
auth       required     pam_tally2.so deny=5 unlock_time=300 magic_root
auth       include              system-auth

account    required     pam_tally2.so
account    include              system-auth

password   include              system-auth

session         required        pam_selinux.so close
session    optional             pam_xauth.so
session         required        pam_selinux.so multiple open verbose
session    include              system-auth

And, here is the system-auth file:

auth            sufficient      pam_ldap.so use_first_pass
ignore_authinfo_unavail
auth            required        pam_unix.so try_first_pass likeauth 
 
account         sufficient      pam_ldap.so
account         required        pam_unix.so
 
password        required        pam_cracklib.so (****** specific
requrements masked ******)
password        sufficient      pam_ldap.so use_authtok
password        required        pam_unix.so use_authtok sha512 shadow
 
session         required        pam_limits.so
#session                required        pam_env.so
session         optional        pam_ssh.so
session         sufficient      pam_ldap.so
session         required        pam_unix.so

I tried adding the following rule to a local policy, but all that did
was make the avc denial for compute_user go away in the logs, everything
else was still the same including the message about unable to get valid
context for root:

selinux_compute_user_contexts(staff_su_t)

I also tried commenting out the pam_selinux.so close in the session, but
that didn't help.

-- 
Stan & HD Tashi Grad 10/08  Edgewood, NM  SWR
PR - Cindy and Jenny - Sammamish, WA  NWR
http://www.cci.org



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-hardened] Re: Help with su (RESOLVED)

[Stan Sander]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On 11/25/2011 08:32 PM, Stan Sander wrote:
> One of the more important things that is currently broken on my system
> when I switch on enforcing mode for SELinux is the su command.  Mostly
> likely I've overlooked something so am asking here first before filing a
> bug on it.  

After doing some more searching, reading, and educating of myself I have
been able to achieve the behavior I was wanting from the su command,
namely change my regular Linux uid to 0 and be able to launch graphical
programs if necessary when logged in to a desktop session.  What I
discovered leaves my SELinux user id set to the user I originally logged
in as, which from a security and accountability standpoint is not a bad
thing, but the role and type are updated so all the transitions needed
for the policy to function as intended can occur.  However, my Linux uid
is 0 so things that need that work.  Probably a simple concept for all
you seasoned SELinux folk, but wanted to document it here for the
benefit of others who may find this in the archives. 

My answer -- removing the calls to pam_selinux.so from the su file in
pam.d and also removing the calls to pam_xauth.so from the su and
newrole files.  These (xauth) generated avc denials when they couldn't
access root's home area at /root due to (I think) ubac constraints.  
The last step a very simple script I called sesu

#!/bin/bash
echo -n "X server:  "
xhost local:localhost
echo -n "Enter root "
su -c "echo -n \"Enter current user \" && newrole -r sysadm_r"

If your PAM config doesn't allow the current user to su, then they get
permission denied.
If SELinux doesn't allow the current user to transition to a sysadm_r
then you get a root shell, but with limited capability. 


-- 
Stan & HD Tashi Grad 10/08  Edgewood, NM  SWR
PR - Cindy and Jenny - Sammamish, WA  NWR
http://www.cci.org



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-hardened] Re: Help with su (RESOLVED)

[Sven Vermeulen]

On Sat, Nov 26, 2011 at 10:00:01PM -0700, Stan Sander wrote:
> After doing some more searching, reading, and educating of myself I have
> been able to achieve the behavior I was wanting from the su command,
> namely change my regular Linux uid to 0 and be able to launch graphical
> programs if necessary when logged in to a desktop session.  What I
> discovered leaves my SELinux user id set to the user I originally logged
> in as, which from a security and accountability standpoint is not a bad
> thing, but the role and type are updated so all the transitions needed
> for the policy to function as intended can occur.  However, my Linux uid
> is 0 so things that need that work.  Probably a simple concept for all
> you seasoned SELinux folk, but wanted to document it here for the
> benefit of others who may find this in the archives. 
> 
> My answer -- removing the calls to pam_selinux.so from the su file in
> pam.d and also removing the calls to pam_xauth.so from the su and
> newrole files.  These (xauth) generated avc denials when they couldn't
> access root's home area at /root due to (I think) ubac constraints.  
> The last step a very simple script I called sesu
> 
> #!/bin/bash
> echo -n "X server:  "
> xhost local:localhost
> echo -n "Enter root "
> su -c "echo -n \"Enter current user \" && newrole -r sysadm_r"
> 
> If your PAM config doesn't allow the current user to su, then they get
> permission denied.
> If SELinux doesn't allow the current user to transition to a sysadm_r
> then you get a root shell, but with limited capability. 

Hi Stan,

This isn't really the way it is meant to resolve. From your denials, I
gather that you were still running in staff_r role. You need to transition
to sysadm_r role first and then try to perform your administrative tasks.

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] Re: Help with su (RESOLVED)

[Stan Sander]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On 11/27/2011 10:38 AM, Sven Vermeulen wrote:
>
> Hi Stan,
>
> This isn't really the way it is meant to resolve. From your denials, I
> gather that you were still running in staff_r role. You need to transition
> to sysadm_r role first and then try to perform your administrative tasks.
>
> Wkr,
> 	Sven Vermeulen
Sven,

Thanks for the tip.  I was running in staff_r when I got the denials.  I
thought I read somewhere that staff was allowed to su, so never thought
the difference of when I entered the newrole to be that significant. 
Anyway, I'll call newrole first but it still appears as though I need to
keep the calls to pam_selinux out of the su file as it fails when they
are in.  Also pam_xauth doesn't appear as though it's able to play with
selinux, at least not inside the su file. 

-- 
Stan & HD Tashi Grad 10/08  Edgewood, NM  SWR
PR - Cindy and Jenny - Sammamish, WA  NWR
http://www.cci.org



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-hardened] Re: Help with su (RESOLVED)

[Sven Vermeulen]

On Sun, Nov 27, 2011 at 12:48:14PM -0700, Stan Sander wrote:
> Thanks for the tip.  I was running in staff_r when I got the denials.  I
> thought I read somewhere that staff was allowed to su, so never thought
> the difference of when I entered the newrole to be that significant. 
> Anyway, I'll call newrole first but it still appears as though I need to
> keep the calls to pam_selinux out of the su file as it fails when they
> are in.  Also pam_xauth doesn't appear as though it's able to play with
> selinux, at least not inside the su file. 

Heh, my bad. There is no need to put pam_selinux for su in the first place.
At least, I don't have it on my systems. The only place where pam_selinux is
called is in the system-login definition for PAM (which is sourced by login,
slim and sshd PAM definitions).

Meh.

	Sven Vermeulen