I've got slimmed down Fedora Core2 that doesn't seem to want to enable selinux after rpm -U'ing the following packages:
policycoreutils-1.14.1-1 selinux-policy-strict-1.14.1-2 libselinux-1.14.1-1
After upgrading to those packages, booting to single user, running fixfiles relabel, and rebooting once more, the system comes up selinux disabled. I've verified /etc/selinux/config SELINUX=permissive and SELINUXTYPE=strict. /etc/sysconfig/selinux sym-links to /etc/selinux/config. Policy resides in /etc/selinux/strict/policy/. Stock FC2 kernel, 2.6.5-1.358smp. I've tried appending selinux in grub as well, to no avail.
What minute detail am I missing?
----- Kirk M. Vogelsang kvogelsa@ccs.neu.edu Northeastern University College of Computer Science
On Wed, 2004-07-07 at 15:38, Kirk Vogelsang wrote:
I've got slimmed down Fedora Core2 that doesn't seem to want to enable selinux after rpm -U'ing the following packages:
policycoreutils-1.14.1-1 selinux-policy-strict-1.14.1-2 libselinux-1.14.1-1
After upgrading to those packages, booting to single user, running fixfiles relabel, and rebooting once more, the system comes up selinux disabled. I've verified /etc/selinux/config SELINUX=permissive and SELINUXTYPE=strict. /etc/sysconfig/selinux sym-links to /etc/selinux/config. Policy resides in /etc/selinux/strict/policy/. Stock FC2 kernel, 2.6.5-1.358smp. I've tried appending selinux in grub as well, to no avail.
What minute detail am I missing?
Update to the latest SysVinit package from the development tree. There are also other relevant packages, e.g. usermode.
On Wed, 7 Jul 2004, Stephen Smalley wrote:
On Wed, 2004-07-07 at 15:38, Kirk Vogelsang wrote:
I've got slimmed down Fedora Core2 that doesn't seem to want to enable selinux after rpm -U'ing the following packages:
policycoreutils-1.14.1-1 selinux-policy-strict-1.14.1-2 libselinux-1.14.1-1
After upgrading to those packages, booting to single user, running fixfiles relabel, and rebooting once more, the system comes up selinux disabled. I've verified /etc/selinux/config SELINUX=permissive and SELINUXTYPE=strict. /etc/sysconfig/selinux sym-links to /etc/selinux/config. Policy resides in /etc/selinux/strict/policy/. Stock FC2 kernel, 2.6.5-1.358smp. I've tried appending selinux in grub as well, to no avail.
What minute detail am I missing?
Update to the latest SysVinit package from the development tree. There are also other relevant packages, e.g. usermode.
That did it, thanx.
Having a problem w/ sudo now however:
$ rpm -q selinux-policy-strict sudo selinux-policy-strict-1.14.1-2 sudo-1.6.7p5-27 $ id uid=600(admin) gid=600(admin) groups=10(wheel),600(admin) context=user_u:user_r:user_t $ sudo sh sudo: unable to exec /usr/sbin/sesh: Permission denied $ dmesg audit(1089381994.953:0): avc: denied { execute_no_trans } for pid=845 exe=/usr/bin/sudo path=/usr/sbin/sesh dev=sda3 ino=32091 scontext=user_u:user_r:user_sudo_t tcontext=system_u:object_r:shell_exec_t tclass=file
I receive the same results if running in staff_r or sysadm_r as well.
----- Kirk M. Vogelsang kvogelsa@ccs.neu.edu Northeastern University College of Computer Science
On Fri, 2004-07-09 at 10:18, Kirk Vogelsang wrote:
Having a problem w/ sudo now however:
$ rpm -q selinux-policy-strict sudo selinux-policy-strict-1.14.1-2 sudo-1.6.7p5-27 $ id uid=600(admin) gid=600(admin) groups=10(wheel),600(admin) context=user_u:user_r:user_t $ sudo sh sudo: unable to exec /usr/sbin/sesh: Permission denied $ dmesg audit(1089381994.953:0): avc: denied { execute_no_trans } for pid=845 exe=/usr/bin/sudo path=/usr/sbin/sesh dev=sda3 ino=32091 scontext=user_u:user_r:user_sudo_t tcontext=system_u:object_r:shell_exec_t tclass=file
I receive the same results if running in staff_r or sysadm_r as well.
sudo is presently broken; the SELinux patch and policy for it are being reworked. Hopefully there will be something newer in rawhide soon.
On Fri, 9 Jul 2004, Stephen Smalley wrote:
On Fri, 2004-07-09 at 10:18, Kirk Vogelsang wrote:
Having a problem w/ sudo now however:
$ rpm -q selinux-policy-strict sudo selinux-policy-strict-1.14.1-2 sudo-1.6.7p5-27 $ id uid=600(admin) gid=600(admin) groups=10(wheel),600(admin) context=user_u:user_r:user_t $ sudo sh sudo: unable to exec /usr/sbin/sesh: Permission denied $ dmesg audit(1089381994.953:0): avc: denied { execute_no_trans } for pid=845 exe=/usr/bin/sudo path=/usr/sbin/sesh dev=sda3 ino=32091 scontext=user_u:user_r:user_sudo_t tcontext=system_u:object_r:shell_exec_t tclass=file
I receive the same results if running in staff_r or sysadm_r as well.
sudo is presently broken; the SELinux patch and policy for it are being reworked. Hopefully there will be something newer in rawhide soon.
Thanx once again Stephen...
----- Kirk M. Vogelsang kvogelsa@ccs.neu.edu Northeastern University College of Computer Science
On Fri, Jul 09, 2004 at 12:15:58PM -0400, Stephen Smalley wrote:
audit(1089381994.953:0): avc: denied { execute_no_trans } for pid=845 exe=/usr/bin/sudo path=/usr/sbin/sesh dev=sda3 ino=32091 scontext=user_u:user_r:user_sudo_t tcontext=system_u:object_r:shell_exec_t tclass=file
I receive the same results if running in staff_r or sysadm_r as well.
sudo is presently broken; the SELinux patch and policy for it are being reworked. Hopefully there will be something newer in rawhide soon.
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.
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?
Thanks...
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#id30045... 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.
On Mon, Jul 12, 2004 at 08:12:54AM -0400, Stephen Smalley wrote:
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.
Actually, the user should newrole to sysadm_r before they're allowed to execute sudo/su. Or, if you want to make life easier for the user, sudo/su could be allowed to perform a role transition on its own, but it should *never* change the identity.
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.
Nonsense. you can allow your IDENTITIES (context users) to have the ability to attain an administrative role which then lets them have the completely orthogonal USER (unix user id). It seems that Fedora/SELinux is attempting to entirely replace the uid/gid concept instead of augmenting it; and in the process appears to have misplaced the difference between uid and euid. (which is not to say that uid/euid ever really worked right in unix)
[ For example, the system really SHOULD know the difference between user "emf" su'ing to user "joe" and running joe's .bashrc. When I do that, I am not joe, I am merely impersonating him for some reason. ]
uid/gid isn't what's wrong with unix authentication; "root" is. [ "root" meaning shared identities; privleged or otherwise. ]
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#id30045... 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.
I find that I must agree with the dissenting viewpoint. Changing the identity is a terrible idea. Having daemons running in pseudouser identities could just as well be handled by having unix_uid along with an unprivleged user_u identity and a ${daemon}_r:${daemon}_t context. We don't need ${daemon}_u as well, and user_u can do far too much by default in FC2.
It would be really nice if this were a tunable as well, since some folks appear to want the identity transition, but I personally think that the "Strict" configuration should disable ID transition.
That's all.
On Mon, 2004-07-12 at 09:14, Erik Fichtner wrote:
Actually, the user should newrole to sysadm_r before they're allowed to execute sudo/su. Or, if you want to make life easier for the user, sudo/su could be allowed to perform a role transition on its own, but it should *never* change the identity.
That requires that the original SELinux user identity be authorized for sysadm_r in the first place, in which case he can directly login or newrole to sysadm_r. That is contrary to the model for sudo, where you want to authorize the user to perform specific tasks with admin privileges without giving him access to a full admin shell.
Nonsense. you can allow your IDENTITIES (context users) to have the ability to attain an administrative role which then lets them have the completely orthogonal USER (unix user id).
Not sure we are communicating here. If the SELinux user identity is authorized for sysadm_r, then he can directly login or newrole to sysadm_r and run anything in sysadm_r (that is executable by sysadm_t). sudo is supposed to let you authorize a given user to perform a specific command with admin privileges without giving them full administrative access.
[ For example, the system really SHOULD know the difference between user "emf" su'ing to user "joe" and running joe's .bashrc. When I do that, I am not joe, I am merely impersonating him for some reason. ]
Yes, but as joe's .bashrc is under his control, you don't want to run it with your own set of privileges.
It would be really nice if this were a tunable as well, since some folks appear to want the identity transition, but I personally think that the "Strict" configuration should disable ID transition.
Easy enough to support in the policy, but you would also need a different /etc/pam.d/su depending on your policy.
One other note on this topic: Most Fedora SELinux users are not maintaining policy/users at present for individual users (beyond system_u/user_u/root distinctions) due to the lack of integrated user management, so they cannot take full advantage of the SELinux user identity and user-role authorizations. setools and setools-gui provide some help in this area, but not if you are using a distributed user database like NIS or LDAP. As a consequence, the typical approach among older SELinux users of individually authorizing staff users for staff_r and sysadm_r is problematic for the typical Fedora SELinux user.
selinux@lists.fedoraproject.org
-
Erik Fichtner -
Kirk Vogelsang -
Stephen Smalley