Darren, your first use case is exactly what we are looking at doing at .Sun Engineering and it would be great to get the role to role implemented so I can remove the hack we use to add "roles=role" to user_attr.
cheers, /Martin On 23 jun 2008, at 03:20, Darren J Moffat wrote: > 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 > _______________________________________________ > security-discuss mailing list > security-discuss at opensolaris.org cheers, /Martin -- Martin Englund, Security Engineer, .Sun Engineering, Sun Microsystems Inc. Email: martin.englund at sun.com Time Zone: GMT-3 PGP: 1024D/AA514677 "The question is not if you are paranoid, it is if you are paranoid enough."
