# SELinux constraint violation on su

## courage

Hi!

It seems I have finally set up SELinux on my Gentoo and fixed all problems related to SELinux, but still one exists and I can't seem to figure out how to solve it.

The problem appears each time I "su" into root, so this is how I log into my system (I use SSH keys, everything else is blocked):

```
Putty->Saved sessions->Server

(displays shell)

newrole -r sysadm_r

(asks for user password)

su

(asks for root password)

#
```

At the "#" point I get a denial (though everything works fine):

```
type=USER_LOGIN msg=audit(1503599777.103:8860): pid=11469 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=192.168.1.99 addr=192.168.1.99 terminal=/dev/pts/1 res=success'

type=USER_AUTH msg=audit(1503599789.913:8861): pid=11485 uid=1000 auid=4294967295 ses=4294967295 subj=staff_u:staff_r:chkpwd_t msg='op=PAM:unix_chkpwd acct="john" exe="/sbin/unix_chkpwd" hostname=? addr=? terminal=? res=success'

type=USER_AUTH msg=audit(1503599802.993:8862): pid=11493 uid=1000 auid=4294967295 ses=4294967295 subj=staff_u:sysadm_r:sysadm_su_t msg='op=PAM:authentication grantors=pam_unix,pam_permit acct="root" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/1 r$

type=USER_ACCT msg=audit(1503599803.004:8863): pid=11493 uid=1000 auid=4294967295 ses=4294967295 subj=staff_u:sysadm_r:sysadm_su_t msg='op=PAM:accounting grantors=pam_unix,pam_permit acct="root" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/1 res=s$

type=AVC msg=audit(1503599803.005:8864): avc:  denied  { search } for  pid=11493 comm="su" name="root" dev="sdc4" ino=9043969 scontext=staff_u:sysadm_r:sysadm_su_t tcontext=root:object_r:user_home_dir_t tclass=dir permissive=0

type=CRED_ACQ msg=audit(1503599803.005:8865): pid=11493 uid=1000 auid=4294967295 ses=4294967295 subj=staff_u:sysadm_r:sysadm_su_t msg='op=PAM:setcred grantors=pam_unix,pam_permit acct="root" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/1 res=succe$

type=AVC msg=audit(1503599803.006:8866): avc:  denied  { search } for  pid=11493 comm="su" name="root" dev="sdc4" ino=9043969 scontext=staff_u:sysadm_r:sysadm_su_t tcontext=root:object_r:user_home_dir_t tclass=dir permissive=0

type=AVC msg=audit(1503599803.006:8867): avc:  denied  { search } for  pid=11493 comm="su" name="root" dev="sdc4" ino=9043969 scontext=staff_u:sysadm_r:sysadm_su_t tcontext=root:object_r:user_home_dir_t tclass=dir permissive=0

type=USER_START msg=audit(1503599803.006:8868): pid=11493 uid=1000 auid=4294967295 ses=4294967295 subj=staff_u:sysadm_r:sysadm_su_t msg='op=PAM:session_open grantors=pam_limits,pam_env,pam_unix,pam_permit,pam_env,pam_xauth acct="root" exe="/bin/su" hos$

type=USER_ROLE_CHANGE msg=audit(1503599803.007:8869): pid=11501 uid=0 auid=4294967295 ses=4294967295 subj=staff_u:sysadm_r:sysadm_su_t msg='op=su acct="john" exe="/bin/su" hostname=localhost addr=127.0.0.1 terminal=/dev/pts/1 res=success'
```

From here it seems that "su" searches something in the root's user_home_dir_t (what does it look for?)

This seems like a cosmetic problem since I haven't noticed any problems. A bad way to deal with cosmetic problems is to create a new policy, but this is what audit2allow has to say about it:

```
audit2allow -a

#============= sysadm_su_t ==============

#!!!! This avc is a constraint violation.  You would need to modify the attributes of either the source or target types to allow this access.

#Constraint rule:

#       constrain dir { ioctl read write create getattr setattr lock relabelfrom relabelto append map unlink link rename execute swapon quotaon mounton add_name remove_name reparent search rmdir open audit_access execmod } ((u1 == u2 -Fail-)  or (u1 == system_u -Fail-)  or (u2 == system_u -Fail-)  or (t1 != ubac_constrained_type -Fail-)  or (t2 != ubac_constrained_type -Fail-)  or (t1 == ubacfile -Fail-) ); Constraint DENIED

#       Possible cause is the source user (staff_u) and target user (root) are different.

allow sysadm_su_t user_home_dir_t:dir search;
```

The last comment line explains why the action was denied, but is there a way to fix it?

(maybe change the "su" behaviour not to look for that "something"? How could I find what is it?)

I use logcheck and this is making my e-mails bit ugly, so any help will be much appreciated.

----------

## Oruriz

Looks like staff_u cannot use su

But it possible to use sudo:

```
emerge -a --noreplace sudo
```

then edit /etc/sudousers through visudo:

```
visudo
```

and add this to User privilege specification:

```
Defaults:youruser runaspw, passwd_tries=3, timestamp_timeout=5                  

youruser ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t ALL
```

and then you can do any root comand (except su) from sudo:

```
youruser@NONAME /home/youruser $ id -Z

staff_u:staff_r:staff_t

youruser@HOSTNAME /home/youruser $ sudo id -Z

Password: 

staff_u:sysadm_r:sysadm_t

```

If you want to use root user you need to login as:

sysadm_u. 

So create 1 more user for administration and login directly into it (no way to change usercontext after login).

----------

## Oruriz

you can use 

```
sudo -i
```

as su replacement.

----------

