Problems with sudo on FC6

[Ted Rule]

I'm trying to build a new FC6 machine to replace my aging FC4 box.

As with the FC4 box, I'd like to retain SELinux's strict policy in
enforcing mode.

Eventually, I would like to run the machine up to run-level 5 in strict
enforcing as I had done with FC4. For the present, all the testing is in
run-level 3 on the console itself, as GDM login currently fails with
SELinux enforcing and I haven't yet enabled sshd.

The first big hurdle I'm facing is sudo. On my old FC4 machine, I was
able to add a user to /etc/sudoers, enable the "user_canbe_sysadm"
tunable and recompile and reload the policy. Admittedly, I had to tweak
policy to allow sudo's stdout to be pipeable, but asides from that I
mostly had the ability to leave the machine permanently in
strict/enforcing.

The FC6 machine was installed on a fresh disk, whereafter I
reset /etc/sysconfig/selinux SELINUXTYPE=strict, touched /.autorelabel
and rebooted.


I've updated the machine to all the latest FC6-Updates, in particular:

 kernel-2.6.18-1.2869.i686.rpm
 selinux-policy-strict-2.4.6-13.fc6.noarch.rpm


Having amended /etc/sudoers to grant a "fred" test user sudo permission,
I saw AVC's indicating the inability of sudo to write
into /var/run/sudo, as well as an AVC indicating that sudo wasn't
allowed to execute /bin/cat, i.e.: 

type=USER_AUTH msg=audit(1167906300.693:29): user pid=3072 uid=0
auid=500 subj=user_u:user_r:user_sudo_t:s0 msg='PAM: authentication
acct=fred : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=tty2
res=success)'
type=USER_ACCT msg=audit(1167906300.700:30): user pid=3072 uid=0
auid=500 subj=user_u:user_r:user_sudo_t:s0 msg='PAM: accounting
acct=fred : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=tty2
res=success)'
type=AVC msg=audit(1167906300.700:31): avc:  denied  { write } for
pid=3072 comm="sudo" name="fred" dev=hda7 ino=420634
scontext=user_u:user_r:user_sudo_t:s0
tcontext=user_u:object_r:pam_var_run_t:s0 tclass=dir
type=SYSCALL msg=audit(1167906300.700:31): arch=40000003 syscall=5
success=no exit=-13 a0=8c1afd0 a1=241 a2=180 a3=8c1afd0 items=0
ppid=3013 pid=3072 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=0
sgid=500 fsgid=0 tty=tty2 comm="sudo" exe="/usr/bin/sudo"
subj=user_u:user_r:user_sudo_t:s0 key=(null)
type=CRED_ACQ msg=audit(1167906300.702:32): user pid=3072 uid=0 auid=500
subj=user_u:user_r:user_sudo_t:s0 msg='PAM: setcred acct=root :
exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=tty2 res=success)'
type=AVC msg=audit(1167906300.702:33): avc:  denied  { search } for
pid=3072 comm="sudo" scontext=user_u:user_r:user_sudo_t:s0
tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=key
type=SYSCALL msg=audit(1167906300.702:33): arch=40000003 syscall=288
success=no exit=-13 a0=0 a1=fffffffd a2=0 a3=0 items=0 ppid=3013
pid=3072 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=tty2 comm="sudo" exe="/usr/bin/sudo"
subj=user_u:user_r:user_sudo_t:s0 key=(null)
type=USER_START msg=audit(1167906300.703:34): user pid=3072 uid=0
auid=500 subj=user_u:user_r:user_sudo_t:s0 msg='PAM: session open
acct=root : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=tty2
res=success)'
type=USER_END msg=audit(1167906300.703:35): user pid=3072 uid=0 auid=500
subj=user_u:user_r:user_sudo_t:s0 msg='PAM: session close acct=root :
exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=tty2 res=success)'
type=AVC msg=audit(1167906300.704:36): avc:  denied  { execute } for
pid=3072 comm="sudo" name="cat" dev=hda2 ino=323546
scontext=user_u:user_r:user_sudo_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
type=SYSCALL msg=audit(1167906300.704:36): arch=40000003 syscall=11
success=no exit=-13 a0=806e2e0 a1=bfd618e8 a2=8c26500 a3=8c26500 items=0
ppid=3013 pid=3072 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=tty2 comm="sudo" exe="/usr/bin/sudo"
subj=user_u:user_r:user_sudo_t:s0 key=(null)


Somewhat bizarrely, of course, sudo continues to run even if it fails to
write into /var/run/sudo. I guess this is arguably a bug in sudo itself,
albeit relatively harmless.


Setting SELinux to permissive, sudo worked Ok.


I also tried changing "fred" from user_u to staff_u, since FC4 defaulted
to only allowing for staff_u to use sudo, as in:

# semanage login -a -s staff_u fred

I then rm -rf'ed /var/run/sudo/*, and restorecon'ed /home/fred to
correct the home directory labelling.


This also failed with SELinux enforcing, and worked in permissive,
giving similar AVC's where previous references to "user_..." appeared
instead as "staff_..."

I had a look at the various booleans available in the policy, and none
seem to be relevant to this problem.

All in all, I can't see an easy way of making sudo work, but the fact
that the user_sudo_t and staff_sudo_t domains exist implies that the
policy contains support for running sudo from either user_r or staff_r.


Can anyone assist me in getting sudo to work on FC6/strict?


Thanks,


-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/