[gentoo-hardened] Selinux: /bin/su and pam_selinux

[gentoo-hardened] Selinux: /bin/su and pam_selinux

[Robert Sharp]

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

Hi,

I have been wrestling with a problem for some time and I cannot see what 
I am doing wrong. Here is an outline:

AIM - to be able to su to root and switch off strict mode in case 
something goes wrong. I was using newrole but I kept forgetting so I am 
trying to use pam_selinux to change the role to sysadm_r. I followed the 
instructions given at 
http://blog.siphos.be/2013/04/how-logins-get-their-selinux-user-context/ 
in general, but I had to do some research to find out how to apply them 
for /bin/su.

The answer was in su.if, added to the "su_role_template" interface. I 
then spent some time figuring out how to get the roles/sysadm module to 
use my modified interface (put it in the same directory) and it 
generally seemed to work. I got a few extra AVCs but I ended up with the 
following:

         optional_policy(`
                 domain_subj_id_change_exemption($1_su_t)
                 domain_role_change_exemption($1_su_t)

                 selinux_validate_context($1_su_t)
                 selinux_compute_access_vector($1_su_t)
                 selinux_compute_create_context($1_su_t)
                 selinux_compute_relabel_context($1_su_t)
                 selinux_compute_user_contexts($1_su_t)

                 seutil_read_config($1_su_t)
                 seutil_read_default_contexts($1_su_t)

                 userdom_relabelto_user_ptys($1_su_t)
                 userdom_dontaudit_relabelfrom_user_ptys($1_su_t)
                 userdom_use_user_ptys($1_su_t)
                 allow $1_su_t self:process setkeycreate;
                 allow $1_su_t $3:key manage_key_perms;
         ')

The PROBLEM: I still get two AVCs that I don't think I should be getting:

     type=PROCTITLE msg=audit(1485020695.038:10367): 
proctitle=2F62696E2F7375002D
     type=PATH msg=audit(1485020695.038:10367): item=0 name="/dev/pts/3" 
inode=6 dev=00:12 mode=020620 ouid=501 ogid=5 rdev=88:03
         obj=staff_u:object_r:user_devpts_t nametype=NORMAL
     type=CWD msg=audit(1485020695.038:10367): 
cwd="/home/robert/selinux/sysadm"
     type=SYSCALL msg=audit(1485020695.038:10367): arch=c000003e 
syscall=188 success=yes exit=0 a0=375183c820 a1=3817fb1fcaa
         a2=375183bce0 a3=1c items=1 ppid=17744 pid=20374 
auid=4294967295 uid=501 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 
fsgid=0 tty=pts3
         ses=4294967295 comm="su" exe="/bin/su" 
subj=staff_u:sysadm_r:sysadm_su_t key=(null)
     type=AVC msg=audit(1485020695.038:10367): avc:  denied  { relabelto 
} for  pid=20374 comm="su" name="3" dev="devpts" ino=6
         scontext=staff_u:sysadm_r:sysadm_su_t 
tcontext=root:object_r:user_devpts_t tclass=chr_file permissive=1
----
     type=AVC msg=audit(1485020695.038:10368): avc:  denied  { create } 
for  pid=20374 comm="su" scontext=staff_u:sysadm_r:sysadm_su_t
         tcontext=root:sysadm_r:sysadm_t tclass=key permissive=1

I double checked that I had corresponding rules to allow these:

     # sesearch -s sysadm_su_t -t user_devpts_t -A
     allow sysadm_su_t user_devpts_t:chr_file { read getattr write ioctl 
relabelto open append };

     # sesearch -s sysadm_su_t -t sysadm_t -c key -A
     allow sysadm_su_t sysadm_t:key { search setattr read create write 
link view };

So I really cannot see why I am getting these AVCs. I keep looking at 
the scripts, the rules and the AVCs to see if I have done something 
stupid, but I cannot see it. I have started making fairly arbitrary 
changes to see if I can make it go away but I am just wasting time 
really. If I cannot figure this out I suspect I will be ditching 
pam_selinux and reverting to explicitly issuing newrole. I guess with 
strict on I will quickly be reminded that I have forgotten to change 
roles anyway.

Thanks in advance,

Robert Sharp


[-- Attachment #2: Type: text/html, Size: 5474 bytes --]

Re: [gentoo-hardened] Selinux: /bin/su and pam_selinux

[Luis Ressel]

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

On Sat, 21 Jan 2017 18:04:51 +0000
Robert Sharp <selinux@sharp.homelinux.org> wrote:

>      type=AVC msg=audit(1485020695.038:10368): avc:  denied
> { create } for  pid=20374 comm="su"
> scontext=staff_u:sysadm_r:sysadm_su_t tcontext=root:sysadm_r:sysadm_t
> tclass=key permissive=1

I haven't looked at this in detail, so please forgive me if my answer
is utter nonsense: Have you considered that this denial might be caused
by UBAC (that's the fancy name for the restrictions refpolicy places
upon interactions between different selinux users, staff_u and root in
this case)?

Anyway, personally I've never tried making su work with SELinux.
"sudo -r sysadm_r -t sysadm_t" works like a charm.

Regards,
Luis Ressel

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

Re: [gentoo-hardened] Selinux: /bin/su and pam_selinux

[Sven Vermeulen]

On Sat, Jan 21, 2017 at 06:04:51PM +0000, Robert Sharp wrote:
>    AIM - to be able to su to root and switch off strict mode in case
>    something goes wrong. I was using newrole but I kept forgetting so I am
>    trying to use pam_selinux to change the role to sysadm_r. I followed
>    the instructions given at
>    [1]http://blog.siphos.be/2013/04/how-logins-get-their-selinux-user-cont
>    ext/ in general, but I had to do some research to find out how to apply
>    them for /bin/su.

Generally, such a change is best implemented through sudo rather than su.
With sudo, you have more control over role and type switching as well
(sudo is SELinux-aware, and not just through its PAM support).

Would that be an option for you? If not, then let's get into the details of
what you are noticing further...

>    The answer was in su.if, added to the "su_role_template" interface. I
>    then spent some time figuring out how to get the roles/sysadm module to
>    use my modified interface (put it in the same directory) and it
>    generally seemed to work. I got a few extra AVCs but I ended up with
>    the following:
> 
>            optional_policy(`
>                    domain_subj_id_change_exemption($1_su_t)
>                    domain_role_change_exemption($1_su_t)
>                    selinux_validate_context($1_su_t)
>                    selinux_compute_access_vector($1_su_t)
>                    selinux_compute_create_context($1_su_t)
>                    selinux_compute_relabel_context($1_su_t)
>                    selinux_compute_user_contexts($1_su_t)
>                    seutil_read_config($1_su_t)
>                    seutil_read_default_contexts($1_su_t)
>                    userdom_relabelto_user_ptys($1_su_t)
>                    userdom_dontaudit_relabelfrom_user_ptys($1_su_t)
>                    userdom_use_user_ptys($1_su_t)
>                    allow $1_su_t self:process setkeycreate;
>                    allow $1_su_t $3:key manage_key_perms;
>            ')

Note that, with this in place, you might be granting more people than you
originally intended to gain certain privileges.

>    The PROBLEM: I still get two AVCs that I don't think I should be
>    getting:
> 
>        type=PROCTITLE msg=audit(1485020695.038:10367):
>    proctitle=2F62696E2F7375002D
>        type=PATH msg=audit(1485020695.038:10367): item=0 name="/dev/pts/3"
>    inode=6 dev=00:12 mode=020620 ouid=501 ogid=5 rdev=88:03
>            obj=staff_u:object_r:user_devpts_t nametype=NORMAL
>        type=CWD msg=audit(1485020695.038:10367):
>    cwd="/home/robert/selinux/sysadm"
>        type=SYSCALL msg=audit(1485020695.038:10367): arch=c000003e
>    syscall=188 success=yes exit=0 a0=375183c820 a1=3817fb1fcaa
>            a2=375183bce0 a3=1c items=1 ppid=17744 pid=20374
>    auid=4294967295 uid=501 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>    fsgid=0 tty=pts3
>            ses=4294967295 comm="su" exe="/bin/su"
>    subj=staff_u:sysadm_r:sysadm_su_t key=(null)
>        type=AVC msg=audit(1485020695.038:10367): avc:  denied  { relabelto
>    } for  pid=20374 comm="su" name="3" dev="devpts" ino=6
>            scontext=staff_u:sysadm_r:sysadm_su_t
>    tcontext=root:object_r:user_devpts_t tclass=chr_file permissive=1
>    ----
>        type=AVC msg=audit(1485020695.038:10368): avc:  denied  { create }
>    for  pid=20374 comm="su" scontext=staff_u:sysadm_r:sysadm_su_t
>            tcontext=root:sysadm_r:sysadm_t tclass=key permissive=1
> 
>    I double checked that I had corresponding rules to allow these:
> 
>        # sesearch -s sysadm_su_t -t user_devpts_t -A
>        allow sysadm_su_t user_devpts_t:chr_file { read getattr write ioctl
>    relabelto open append };
> 
>        # sesearch -s sysadm_su_t -t sysadm_t -c key -A
>        allow sysadm_su_t sysadm_t:key { search setattr read create write
>    link view };
> 
>    So I really cannot see why I am getting these AVCs. I keep looking at
>    the scripts, the rules and the AVCs to see if I have done something
>    stupid, but I cannot see it. I have started making fairly arbitrary
>    changes to see if I can make it go away but I am just wasting time
>    really. If I cannot figure this out I suspect I will be ditching
>    pam_selinux and reverting to explicitly issuing newrole. I guess with
>    strict on I will quickly be reminded that I have forgotten to change
>    roles anyway.

As was mentioned in the thread already, this might be UBAC-related.

Wkr,
  Sven Vermeulen