Hm, yes, I see where you are coming from.

I think this is an area where the OSS world has the infrastructure, but
not the details to pull off what you want. I am personally a bit loathe to
suggest adding yet another service to the mix of account management,
especially given that it's unlikely to be supported by Win/Mac any time
soon, whereas the LDAP solution is already what they do. Hence why I would
suggest something tying into that. I can see the benefit of the service
you are suggesting though.

*Diverges a bit into LDAP*
In a perfect world, I would have the machine in the LDAP tree, with
containers of some description off for various services, and/or a default.
The containers would hold a list of allow/deny groups. It would be
possible to alias groups for allow/deny lists, along with creating custom
groups just for that service on that machine if so desired.

As a simple example, the mail server could have an shell group with one
allow entry point to the 'all users' group for imap/smtp access, and shell
group with a pointer to the sysadmins group.

If this was standardized into pam_ldap, then that would utilize existing
infrastructure. If you're going to hack C code in the security libs, it
would probably be better to do it with established work, plus it would
save you writing a server. Given that GSSAPI is already support for
NSS/PAM, you could still use Kerberos to keep the data secure, and allow
machines to change thier own ACL's via their host key.

Hmm, maybe this should be a project of mine... (maybe)

> On Tue, Jan 22, 2008 at 06:38:50PM +1300, Edward Murrell wrote:
>> Sounds like something that would be better served using LDAP groups,
>> that way it could hook into existing infrastructure.

> Well, currently I'm using PADL's support for the pam_filter keyword in
> /etc/ldap.conf but it feels like a hack. I haven't been able to figure out
> how
> to do this otherwise with the existing software. The O'Reilly LDAP book
> makes
> some suggestions in this area but they don't scale well.
>> However, the current PADL pam implementation (last I looked anyway)
>> wasn't especially brilliant at providing control for lots of hosts with
>> lots of users. It was possible to cobble something together
>> using /etc/security/access.conf, but it always felt... odd. Maybe look
>> into updating that?

> Well, I'd rather not have to edit files on each machine as I have to do
> today
> (each machine will have its own customized version of ldap.conf) as it
> means
> that the authorization decision is no longer truly centralized.
> I'm really looking for a lightweight security mechanism I can hook into
> PAM: a
> small client which securely connects to one of a set of authorization
> servers,
> passing the chosen server some data and receiving back an authorization
> decision. The authorization server in turn can be very simple as it is
> just a
> Kerberized conduit for passing the data from the client to some backend
> and
> passing the backend's decision back to the client. The backend can use any
> data store; I'd rather net tie it to LDAP directly as it would require me
> to
> mess with LDAP objects and schema's, something I'm trying to avoid.
> To paraphrase, I'm looking for something akin to a Kerberized
> tcpclient/tcpserver (part of djb's ucspi-tcp). That might be close enough
> for
> this purpose that only minor modifications would be necessary.
> Cheers,
> Jos
>> Cheers,
>> Edward
>> On Mon, 2008-01-21 at 14:36 -0800, Jos Backus wrote:
>> >
>> > The server:
>> > - accepts some client-generated request (containing service,
>> > principal/username, hostname, etc.) over TCP;
>> > - sends this data to a backend application;
>> > - receives the response ('authorized' or 'not authorized') from the
>> > backend;
>> > - relays the response to the client.
>> >
>> > The client is called by pam_exec from the account group, so it has
>> > access to
>> > the username; the realm could be supplied on the command line. The
>> > client
>> > could try multiple authorization servers to ensure availability.
>> >
>> > The backend application could simply query a database which is
>> > maintained by
>> > another application (presumably with an easy to use web frontend).
>> >
>> > Thoughts? Would I be better off using GSSAPI instead?


> --
> Jos Backus
> jos at