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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
