[OpenAFS] Authenticating against krb5-only KDC (active directory)

[Derek Atkins]

(forwarding back to openafs-info, where this belongs)

Martin Schulz <schulz@iwrmm.math.uni-karlsruhe.de> writes:

> Derek Atkins <derek@ihtfp.com> writes:
> 
> > Indeed, you are not the first to do this.  I implemented something
> > exactly like this for Krb5-NFS while I was working at Sun back in '95.
> > The problem is that you either:
> > 
> >  a) have to port krb5 into the kernel, or
> >  b) have to have some userspace daemon that:
> >     1) knows each user's Krb5 TGT
> >     2) takes kernel upcalls to obtain tokens from the TGT
> 
> Oh, I see. The problem is to make the cachemanager aware of the krb5
> tickets, right? 

That seems to be what you implied.

> The information where to find these ticket is stored in the KRB5CCNAME
> environment variable of the process that tries to access a given
> file. How far is this information carried into the operation system?

environment variables are all user-space constructs.  They don't exist
in the kernel and, AFAIK, are not accessible from the kernel.

> I must admit, I never thought any further than the (g)libc.... The
> open() function should still have that environment available, right? 
> What happens then?

open() in glibc calls open() syscall with a well-defined interface.

> > At Sun we implemented (b).
> > 
> > Basically, there needs to be two (new) user-space programs:
> >  - 'aklogd' which is the magic daemon application, and
> >  - 'aklog.new' which registers the user's TGT with aklogd and
> >    associates it with the user's UID or PAG.
> 
> If the ticket is bound to the uid only, life is simple: just look for
> a /tmp/krb5cc_$UID file. Since the afsd runs as root anyway it will be
> able to read it.

This is not guaranteed, and if you do this it could be a security
hole.  Some applications use /tmp/krb5cc_<tty_name>.  Some users set
special functions to maintain multiple ticket files.  This is exactly
why you need to register your TGT (or ticket file) with the system
manually.

Also, you clearly don't understand how afsd works.  By the time the
user is accessing afs, all the AFSD processes are sitting in the
kernel, in afs_syscall, never to return to user-space until the system
shuts down.  Thinking that afsd can help because it runs as root is
looking in the wrong direction (sort of).

> If you have different sessions for the same user, there there will be
> different processes with different values for $KRB5CCNAME. They
> usually all point to some file /tmp/krb5cc_$UID_$RANDOM readable by
> the uid. So this is protection only against accidents, not against
> fraud (any malicious process could read other credentials for the same
> uid). The classification of the processes to PAGs recurs to the
> different assigned values for $KRB5CCNAME.

Agreed.

> > Then the cache manager would have to use a local RPC-like transport to
> > talk to the aklogd process in order to obtain the appropriate tokens.
> > They bind the request to the UID/PAG of the user's context in order to
> > get the right TGT from the daemon.
> > 
> > Question1: what if the user specifically wants tokens for one cell but
> > not another?
> 
> Set up a proper ticket file with only those tickets that should be
> used and make $KRB5CCNAME point to it.

Is it possible to setup a ticket file with only a ticket for
afs/athena.mit.edu@ATHENA.MIT.EDU and no TGT?  How does a user do
that?

> > Question2: what if the user wants tokens in one PAG for two cells
> > using two different principals.
> 
> Set up a proper ticket file with tickets for both principals and make
> $KRB5CCNAME point to it.

Can you even do that?  You certainly can't have two TGTs, because
there is no way to know which TGT to use for the particular cell.
Again, I don't think there is an easy way for the user to do this.

The current process of "aklog per cell" solves both these problems.

> > Question3: I can't think of a question 3 right now but I'm sure one exists.
> 
> Sure. But such questions have to be solved anyway if one dreams about
> a k5 based AFS, isn't it? 

Not necessarily.  A lot of it depends on how you envision krb5-based
AFS to work.  The way I envision it is that you still manually
authenticatate to each cell, but I'd like to see each fileserver
in a cell have its own krb5 authentication.

The way I'd like to see it work:

~> aklog -cell athena.mit.edu

[ This registers the current TGT (from KRB5CCNAME) for cell athena.mit.edu ]

Now the cache manager can use this TGT to obtain a ticket for each
file server within the cell.

If the server wants to authenticate to a different cell, they still have
to manually perform:

~> aklog -cell sipb.mit.edu

In other words, I don't expect the user interface to change at all.
I just expect a change "under the covers".

> Yours,
> -- 
> Martin Schulz                             schulz@iwrmm.math.uni-karlsruhe.de
> Uni Karlsruhe, Institut f. wissenschaftliches Rechnen u. math. Modellbildung
> Engesser Str. 6, 76128 Karlsruhe

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com