Kerberized authorization service

[Edward Murrell]

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.

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.'
 
> 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?)

I'll chew over this a bit more...

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