Kerberized authorization service

[Jos Backus]

On Sun, Jan 27, 2008 at 11:35:01AM +1300, edward at murrell.co.nz wrote:
> 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.

While this could no doubt be made to work, it would tie the authorization
plumbing very closely to LDAP, which I don't think is a good idea because of
all the dependencies involved. Additionally, it could prove difficult to
devise an LDAP schema that meets most people/organisations' needs and is
flexible enough to handle uncommon cases.

What I'm envisioning instead is a simple yet secure system that can use any
backend and doesn't require bloating pam_ldap even more. I'd rather see a
separate tool that integrates well with other setups and can be tested
independently and easily (pam_ldap fails this test imo). To start with, the
authorization management application could maintain a SQLite database used by
the authorization server; the database could be replicated using rsync over
ssh. With a flexible choice of backends because of the architecture, LDAP
could be added easily enough if needed.

> 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.

GSSAPI/NSS/PAM bring with them a considerable amount of additional complexity.
I'd much rather stick with pam_exec and a simple command line tool that exits
0 on success, 1 otherwise. This client and server could conceivably be created
from a stripped down rsh{,d}. Frankly I'm very surprised that nobody has
written such a basic service already. It can't be _that_ hard.

> Hmm, maybe this should be a project of mine... (maybe)
 
I only have a very basic understanding of Kerberos but I'd love to help or at
least cheer you on. :-)

Thanks for the feedback, Edward.

Cheers,
Jos

> > 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 catnook.com
> >
> 

-- 
Jos Backus
jos at catnook.com