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. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency