Kerberized authorization service

[Jos Backus]

    Hey Edward,

On Tue, Jan 29, 2008 at 08:06:18PM +1300, Edward Murrell wrote:
> Howdy...
> 
> Something like remctl (I personally have not touched it) would be a good
> start, since it's essentially a remote execution engine. If you did a
> sandboxed remctl server to get this started, you could (hopefully)
> replace the remctl server with a C server running on a dedicated port.

Yeah, it's probably the closest to what I'm looking for. I'll play with it and
see how well it can be made to work with pam_exec.

> I harp on about LDAP, because often organisations already have it in
> place, one way or the other, so if you can leverage that, then many
> admins will be a lot happier. If you don't, your average admin working
> in an enterprise looks at it and says 'Another set of user tables to
> maintain, no thanks.'
  
Well, there are a few issues: 1) we'll have to build this authorization
application anyway, 2) a lot of information about our infrastructure doesn't
reside in LDAP today and 3) cannot be migrated to LDAP easily. LDAP is great
when schemas are well-defined and hardly ever change, but it's not a general
purpose database which is what our deployment system is and needs.  Also,
maybe it's me but I find debugging OpenLDAP painful. It just isn't a good fit
here.  That said, I do envision LDAP as one of the data sources in the mix,
which is why a modular design is important.

> > I only have a very basic understanding of Kerberos but I'd love to help or at
> > least cheer you on. :-)
> 
> Heh, I understand how Kerberos works (or at least, I like to think I do),
> but my several aborted attempts to learn GSSAPI have made my brain hurt.
> The lack of a plain English introduction/explanation to the API is probably
> why Kerberos doesn't have a heck of a lot of application support.
> (Anyone else listening here?)
 
That's an excellent point.

> I'll chew over this a bit more...
 
Thanks. Please let us know what emerges...

Cheers,
Jos

> -Edward
> 
> On Mon, 2008-01-28 at 22:39 -0800, Jos Backus wrote: 
> > 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)
> 
> 
> 

-- 
Jos Backus
jos at catnook.com