Re: Kerberized authorization service
- From: John Hascall <john@xxxxxxxxxxx>
- Date: Tue, 29 Jan 2008 07:40:17 CST
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@xxxxxxxxxxx,foo.iastate.edu,,bar.iastate.edu,ssh
ksu might send:
##,access,john@xxxxxxxxxxx,foo.iastate.edu,root,ttyp6,su
Our management system, moira, might send:
##,add,john@xxxxxxxxxxx,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@xxxxxxxxxxxxx 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 exitsd
0 on success, 1 otherwise. This client and server could conceivably be create
from a stripped down rsh{,d}. Frankly I'm very surprised that nobody hast
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
yhow
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
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@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/kerberos
.
- Prev by Date: Re: Kerberized authorization service
- Next by Date: Re: Kerberized authorization service
- Previous by thread: Re: Kerberized authorization service
- Next by thread: Re: Kerberized authorization service
- Index(es):
Relevant Pages
|
