[redhat-lspp] LSPP Development Telecon 04/10/2006 Minutes

[Klaus Weidner]

On Mon, Apr 17, 2006 at 10:59:08AM -0400, Steve Grubb wrote:
> No quite. I'm thinking of logging in as root which gets the default role 
> sysadm_r. roots password is sufficient for this. Then use newrole to change 
> to secadm_r or auditadm_r, which will prompt for a role's password. newrole 
> (via pam) will query the role password database.

It's not good to default to sysadm_r, since you don't want an audadm user
to have automatic access to that role. Also, I think that shared
passwords are a bad idea; I'd prefer the current approach where newrole
prompts for the individual user's password.

How about changing the semantics of the semanage user mapping, and allow
that file to specify the permitted roles (and default role) instead of
the active role?

Something like the following:

User "jdoe" is authorized to be audit administrator, with SELinux user
class "staff_u", and authorized role "audadm_r".

"jdoe" logs in (using ssh or local login) as Unix user "jdoe", gets
prompted for his "jdoe" password as usual. The user has no special
privileges except for the "staff_u" SELinux user class and "wheel"
group membership, which permit use of su and newrole to change
privileges, but don't in itself allow anything interesting.

When "jdoe" needs to do administrative actions, he uses "su" to change to
root. This prompts for the root password. (Alternatively, use "sudo bash"
which would prompt for the user's current password). The new shell
defaults to the "audadm_r" role since that's the only authorized role for
this user.

For a different user "cnorris" who is authorized for all of the sysadm_r,
secadm_r, and audadm_r roles, you would declare one of these to be the
default role (probably sysadm_r), and the user can switch among the
authorized role (after "su") using "newrole -r". Alternatively, a "-r
ROLE" switch to "su" or "sudo" would be nice.

> > Keeping in mind that different login methods (/bin/login, sshd, and gdm)
> > can have different sets of permitted roles and different orders for such
> > roles there's a lot of potential for confusion.
> 
> I think we should keep it simple. Login as root -> default role. Then change 
> to what you need with newrole.

Agreed, but the default role needs to be user specific; you can't default
to a role that the user isn't permitted to use.

> > Also where would we store such role passwords?  /etc/rshadow?
> 
> Possibly. I think we should determine if this is desirable and necessary 
> first. I have a feeling it is, but Klaus is a better judge of that.

I'm not convinced that there's a need for role passwords. The mapping
could list the permitted roles for the logged in user, and that's what
determines if the user can change to a new role or not. This would
require that the logged in user information stays available and is used
for checking permissions, for example by using the audit UID.

-Klaus