On 10/19/07, Mike Gerdts <mgerdts at gmail.com> wrote: > On 10/19/07, Darren J Moffat <darrenm at opensolaris.org> wrote: > > Jason King wrote: > > > Probably not quite the best description, but since I opened my big > > > mouth last weekend, thought I should probably go ahead and propose > > > this as a formal project. > > > > > > Currently, all of the supported methods of specifying server access > > > control with LDAP (netgroups, or pam_list) involve storing some aspect > > > of the policy on the managed systems themselves. As a result, changes > > > in policy requires touching all impacted servers. I think it would be > > > very useful if this could be centralized in LDAP. > > > > pam_list was purposely per system rather than held in LDAP. Since you > > can use netgroups in pam_list's files that allows you to put the "real" > > policy in the LDAP database. It could be extended to look in LDAP as > > well but that probably requires defining and deploying a new schema. As > > a historical note pam_list actually existed long before we adopted LDAP > > as a nameservice even though it was only recently integrated (my oldest > > SCCS version for it is 99/10/12). > > One key thing that is missing with netgroup in LDAP is the equivalent > of reverse netgroup maps. In NIS, a server can ask "what netgroups > does this user belong to?" and get a reasonable answer. In LDAP, the > server has to say "give me these netgroups so I can search through > them to see if the user is a member." With a large environment, this > has the potential to be a performance problem. I thought I heard that > there was some ongoing work in this area, but I forget the details. > > In addition to pam_list, there is pam_access. While NIH, it does > offer compatibility with existing Linux deployments and presumably BSD > (some of the code in it was lifted from logdaemon which I believe is > of BSD heritage). If you are interested in using pam_access as a > starting point, I did some clean-up on it a long while back that I > would be happy to contribute. Several years ago I was using this > across Solaris, Linux, and HP-UX. Of course, if pam_list is more > desirable, it should also be rather trivial to port to Linux and > others for heterogeneous environments. > > > > Also, there is no easy way to do fine-grained control of group and > > > role membership for LDAP managed systems and still maintain > > > centralized management within LDAP. For example, I might want 'jason' > > > to have access to the 'root' role on systemA, but not systemB. Or, on > > > systemC, 'bob' should have access to different groups than systemD. > > > Any of the ways I can imagine doing this w/ LDAP are not particularly > > > pretty (and have problems). > > > > It shouldn't be limited to LDAP but to any supported nameservice. > > > > I've implemented the enforcement part before of this and a possible > > implementation is in 4986798, have a lot at that CR and see if the > > proposed solution meets your needs. > > > > It is great you want to help implement a project however to do this the > > hard part (and the reason this hasn't been done already) is extending > > smc. Unfortunately smc is also closed source. There maybe light at the > > end of the tunnel though if Visual Panels[1] gets traction. > > Is this intending to imply that to get code into OpenSolaris it must > also have appropriate integration with Sun's tools that are not open > source? That seems like a reasonable gate to get it into Solaris, > which non-Sun people can't do anyway. Having such a gate for > OpenSolaris would have the effect of stopping a wide variety of > sysadmin focused projects. > > -- > Mike Gerdts > http://mgerdts.blogspot.com/ > > > > > Finally I assume since you are proposing a project you actually want to > > write code for this rather than you are asking someone else to do so ? > > > > -- > > Darren J Moffat > > _______________________________________________ > > security-discuss mailing list > > security-discuss at opensolaris.org > > > > > -- > Mike Gerdts > http://mgerdts.blogspot.com/ >
One avenue I wanted to investigate was using some features of LDAP to do some of this: For any pam request, send the info (off the top of my head, this would probably a certain set of well known items -- src user, dest user, hostname, service name, etc) to the LDAP server in an extended operation -- essentially a sort of RPC over ldap, and get a allowed/not allowed response. For any lookup, any search request includes an ldap control containing the hostname that is sent with the ldap search operation. This would cause the server to filter or adjust the results (adding or removing attribute values). As with anything, it presents a certain set of tradoffs -- client simplicity (probably 200 lines or less of code changes), but requires more server support (however, I think all of the commonly used LDAP servers support the necessary plugins), etc.
