On Thu, 2007-01-04 at 14:08 +0000, Ted Rule wrote:
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?
The /var/run/sudo denials seem like a bug in policy, either in the
labeling of that directory or in the allow rules. I see a ifdef TODO
block in sudo.if in the refpolicy that omits rules that were in the
original example policy.
The larger issue though is that in FC4 and earlier, sudo was modified to
transition to a security context for "root" and to execute a helper
(/usr/sbin/sesh) in order to try to provide transparent operation with
SELinux, such that you could have e.g. bash (user_u:user_r:user_t) ->
sudo (user_u:user_r:user_sudo_t) -> sesh (root:sysadm_r:sysadm_t) ->
arbitrarycommand (root:sysadm_r:<sysadm_t or any domain transition from
sysadm_t on the particular command>). This was similar to the su
selinux integration, which used pam_selinux to set up a transition to a
new security context for the new user identity as well. The approach
was driven by transparency/compatibility rather than security, diverged
from the original SELinux model, and caused unexpected problems (as
reported on this list, in bugzilla, and elsewhere).
In FC5 and later, SELinux reverted to its original model for strict
policy, in which a change in Linux uid via su or sudo does not change
SELinux user identity (i.e. authorized role set and range) and one must
separately newrole to perform changes in role or level, and one is
strictly bounded by one's initial login context. Thus, for sudo, you
have to first be in user identity (set upon login) and role (set upon
login or via newrole) authorized for what you want to do, and you have
to set up policy to specify how you want sudo to transition upon
executing the particular commands (other than the shell, which has a
default transition back to the calling domain). Not transparent, but
more correct. userhelper/usermode remains an exception that still has
to be addressed.
--
Stephen Smalley
National Security Agency