[redhat-lspp] Re: newrole, UID change, etc

[Chad Hanson]

> > 
> > Remind me again why newrole followed by su isn't adequate?  I really
> > don't think we want to re-merge uid changes with context changes.
> 
> It's not just convenience, even though I think that's a usability
> concern. (Currently, a "su" without following newrole leaves you in a
> state not useful for any type of system administration.)
> 

I think a "newrole" before the "su" may be more sound as one could have
setuid scripts available to a given role. 

> The important needed feature is that you need to be able to implement
> separation of duties for human administrators, and (as far as I can tell)
> the current system doesn't enforce this properly. For example, consider
> two users "joe" and "bob", where "joe" is permitted to change to the
> "sysadm" role, and "bob" to the "secadm" role.
> 
> Currently, both users would need to be a "staff" user and need to know
> the shared root password. Once they are root, they can newrole to any of
> the administrative roles. There needs to be a place where the permitted
> roles for the original (pre-su) user are stored and checked. (This is
> assuming that people don't log in as root directly.)

The "su" shouldn't change what roles the user can assume because "su" no
longer alters the selinux user identity. The selinux user identity should
still be "joe" and "bob" or "sysadm_u" or "secadm_u" if mappings are in 
use. Thus "joe" in "sysadm_r" as "uid 0" shouldn't be able to newrole to 
"secadm_r" as this isn't valid for selinux user "joe". 

There are issues like "joe" can change "bob"'s password if password
changing is left to the "sysadm" role instead of "secadm". 

-Chad
> 
> There's no need for a separate password database, either the user's
> password or the root password could be used to authenticate the role
> change.
> 
> -Klaus
>