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:
sysadm::::type=role;roles=sysadm;profiles=System Admin
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
helpdesk::::type=role;roles=dbadmin
dbadmin::::type=role;
To make this part of the proposal "official" requires updating the
administrative interfaces. pam_roles doesn't need to be changed at all.
--
Darren J Moffat
