On Fri, 2004-07-09 at 13:28, Erik Fichtner wrote: > That reminds me.... I had this same problem, and I just worked around > it by allowing the avc denies for sudo, and now sudo works as I > expected it to. The original poster showed a denial of executing sesh from user_sudo_t without performing a domain transition. That is definitely not what you want. sudo should transition to a user domain upon executing sesh, most typically to sysadm_r:sysadm_t since it is typically used to assume admin privileges for a particular command. Further, as the caller is typically not directly authorized for an administrative shell, you need sudo to transition to a user identity (e.g. root) that is authorized for the administrative role. > What IS unexpected is that su changes the users' context from "user_u" > (or "emf" or whatever username, naturally..) to "root"... Thus, we lose > the context audit trail of who was puttering around as root. > > Back in the old 2.4 (pre-xattr) SELinux, su never did this (it only > changed uid to 0 and left the context alone), and from my casual reading > of the flask papers; this was on purpose. (ie: it was my understanding > that the USER would never ever change, but the ROLE and TYPE could) > > So what gives? As part of the Fedora SELinux integration, RedHat created a pam_selinux module and changed /etc/pam.d/su to invoke it, so that su performs context transitions, including changing the user identity. Note that the user_canbe_sysadm tunable allows you to disable the ability of user_r:user_t to reach sysadm_r:sysadm_t via su, so that only users authorized for staff_r can do so. That reduces your exposure. See the following for further discussion: http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/index.html#id3004527 http://marc.theaimsgroup.com/?l=selinux&m=107757717110966&w=2 And an argument against have su perform context transitions: http://marc.theaimsgroup.com/?l=selinux&m=107765457418746&w=2 Note that the use of pam_selinux by su has also led to issues with running daemons in pseudo user identities via su, as discussed previously on this list. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
