Role enhancements Proposal
By Darrenmoffat-Oracle on Jun 26, 2008
Allowing role to same role over network
The current implementation of pam_roles has an "allow_remote" module argument that allows the role to be assumed over the network when PAM_AUSER is set. Currently only ssh with hostbased user authentication sets PAM_AUSER.
It also only allows user to role not role to (same) role. However I believe that "role to (same) role" is actually much more useful. Consider the following example case:
Helpdesk users login on a workstation/Sun Ray or something not even running Solaris. They ssh (using any userauth method) to some "Trusted Host". This "Trusted Host" then has network routes to the production machines. It is also possible that "Trusted Host" has some stronger initial user auth (eg, OTP or SecurID).
The helpdesk user assumes a role on "Trusted Host" (this is audited on Trusted Host, maybe also has additional PAM modules to determine when roles can be assumed).
The user (now with ruid of the role) then uses ssh to connect to the appropriate production host as the role.
If no auditing is in use the user doesn't even need to be known on the production host at all just the roles. Even if the user is known they don't need to be allowed to login (eg using pam_list).
This is a reasonably common and in my opinion very sensible architecture. I've heard of this existing at several sites.
This can actually be achieved today by manually editing a roles user_attr(4) entry so that it has a "roles=" entry for itself eg:
However this can't be done using the rolemod(1M) or other admin tools since they currently believe that roles can't have roles.
A fix for this could be integrated into pam_roles so that "allow_remote" allows PAM_AUSER to be the role as well. However this now means that all roles can be remotely assumed by themselves. In my opinion that isn't any weaker a policy than what allow_remote already means.
It also makes sense to me that a role be allowed to "su - rolename" to itself - this has no audit impact but has the advantage of being a nice easy way to "clean" the environment. To allow that roles would need to be able to assume themselves regardless of the value of "allow_remote".
Allowing roles to have roles
In the general case, why can't a role have roles ?
I see no reason why not, in fact I can thing of many cases where allowing roles to have roles actually helps build a more understandable and usable policy.
Continuing with our helpdesk scenario above.
A slightly different implementation is that the user assumes the "helpdesk" role on their workstation and runs tools as helpdesk. Some of those tools need to remotely access production machines. However the users don't have accounts that can login on those remote machines. The only accounts that can login on the production machines are those that represent roles eg "dbadmin" and the "helpdesk" account.
In this case the "dbadmin" role is given to the "helpdesk" shared account as well as some of the core database team.
For this to work we need to allow roles (helpdesk) to have other roles (dbadmin).
Again I think this is a perfectly reasonable deployment case, and one that is already in use without roles. By making helpdesk and dbadmin roles we can increase the security. If we stick with the current "roles don't have roles" then we weaken the security because now one or both of the "helpdesk" and "dbadmin" would be deployed as normal user accounts.
Like above this is actually already possible by manually updating the user_attr(4) entries for the roles, eg
To make this part of the proposal "official" requires updating the administrative interfaces. pam_roles doesn't need to be changed at all.