Kerberized authorization service
John Hascall
john at iastate.edu
Tue Jan 29 08:40:17 EST 2008
We have had a simple kerberized accessd service here for almost
20 years now. It's some pretty ugly code, but if you wanted to
make your own it would be about a day's project. Ours uses the
kind of really trivial protocol one might come up with when one
has a day to create it :)
like:
sendauth(as host/host.name usually) -->
then |------ nul-terminated strings ---------|
2bytes-count 2bytes-opcode princ resource mode wherefrom whatcomment -->
2bytes-count,2bytes-replycode <-- (false/true basically)
for example, sshd (via pam) might send
##,access,john at IASTATE.EDU,foo.iastate.edu,,bar.iastate.edu,ssh
ksu might send:
##,access,john at IASTATE.EDU,foo.iastate.edu,root,ttyp6,su
Our management system, moira, might send:
##,add,john at IASTATE.EDU,foo.iastate.edu,...
delete ...
rename ...
and so on It also supports hierarchical lists (e.g., foo.iastate.edu
contains foo-staff and foo-guests which contain users, etc)
Resource names can be machines or printers or whatever (for example,
we have an apache module that queries it too)
Recently, I had a couple of my student employees work up a
proof-of-concept using SAML (with a kerb auth as part of the payload)
as the protocol -- since SAML seems like a more likely future direction
for a standardized auth protocol than something I threw together one
night in 1990 :)
You could backend such a thing with LDAP or whatever you want
(we use an in-core flattened double-hash structure,
backed with a simple on-disk log-structured copy
so that all operations are more-or-less done in small constant "O(1)" time.
John
> 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 create
d
> 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 ou
t
> > > 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 an
y
> > > 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
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
More information about the Kerberos
mailing list