On Mon, Oct 06, 2008 at 09:06:21AM -0500, Mike Gerdts wrote: > On Fri, Oct 3, 2008 at 4:16 AM, Darren J Moffat <Darren.Moffat at sun.com> > wrote: > > I considered that, but hadn't discussed it with Bart. At one point during > > the development of our proposal we had the ability to specify a profile to > > capture the case of multiple authorisations eg: > > > > pam_authorized.so.1 profile="MyCompany J2EE Logins" > > > > We dropped that yesterday just before I sent out the proposal because we > > thought it might be hard to understand what it mean't. For example does it > > mean any authorization listed in that profile or all of them ? In your > > example it would mean any authorization. > > I like one aspect of this a fair amount. By adding the following to pam.conf: > > ... pam_authorized.so.1 profile="Login to %f"
Me too, but I'd prefer if we stored this in /etc/security/policy.conf, not in pam.conf module arguments. The reason is as follows. With PSARC/2005/275 it will be possible to get pretty close to where users never have to edit /etc/pam.conf, nor any of the pam.conf snippets that we'll ship in /usr/lib/security. That means we can stop writing/maintaining shell script code (i.pamconf in SVR4 packaging) for "editing" pam.conf. Any module which introduces configuration through module arguments will necessarily make it more difficult to get away from such scripts. > I can then manage access control at the directory service level > without per-host configuration. Of course, there is also pam_list > that could accomplish something similar. Various lines for the > various PAM service names could be used for things like "Remote login > to %f", "Console login to %f", and "Legacy remote protocols login to > %f". Yes. BTW, I strikes me that we could use specially constructed user_attr(4) keys for hosts to get something like host_attr with minimal code changes (the LDAP schema for RBAC would change slightly, and so would the nss_ldap code, but nothing else would have to change). > On the down side, it does put a bit of a treasure trove of "how do I > attack this site?" information into the directory service. But I > guess that RBAC is already well down that path. The clients have to be able to read this information, so at best you could disallow access to it only to anonymous LDAP clients. That wouldn't buy you much protection. Nico --
