[OpenAFS-devel] [LKML] Re: In-kernel Authentication Tokens (PAGs)

[Kyle Moffett]

On Jul 14, 2004, at 05:30, Tomas Olsson wrote:
> Kyle Moffett <mrmacman_g4@mac.com> writes:
>
>> setuid() et. al. require no additional logic because they just modify
>> UID/GID.  If there are any key-rings associated with the UID/GID, 
>> those
>> won't be available any more and the ones of the new UID/GID will, but
>> that is the only changing one part of the set.  On the other hand, 
>> keys
>> that are not linked through the UID or GID will remain the same 
>> without
>> explicit manipulation.  This makes it easy for me to give a setuid
>> program the ability to read in a file from my AFS home.
>>
> Nice. Sessions only change upon explicit KEYCTL_SET(KEY_SESSION, ...)?
>
> Is there any way to figure out or be notified when a certain key is no
> longer referenced? I suppose you do some refcounting.

Keys will have refcounts, and when the refcount hits zero it will be 
deleted.
Kernel stuff will be able to register a set of callbacks with a 
key-type to control
creation, deletion, modificiation, etc.

>>> KEYCTL_SHLOCK
>>> KEYCTL_EXLOCK
>>> KEYCTL_UNLOCK:	A mandatory lock on the key/key-ring
>>
> Be careful with those :)
> Are the locks connected to the open file, and discarded on close?

Probably only privileged processes (CAP_LINUX_KEYRING?) or maybe
those with write privileges will be able to use those (Even the SHLOCK).

> Then there is the question about default PAGs and the PAG jail. I'm 
> still
> not sure if those are necessary or even desirable. The way the current 
> AFS
> implementations seems to work is that if you don't have an allocated 
> PAG
> (PAG@localhost session key?), your uid is used as the key under which 
> to
> store your tokens. This is handy as you don't need to initialize 
> tokens for
> every login if you do several. Also, once you have a real PAG, you 
> can't
> touch your default, or any other PAGs. This can be used as a kind of 
> jail,
> creating an unauthenticated context where it doesn't matter that I 
> don't
> know what I'm doing.

By default, a NULL (not an empty) key-ring is associated with init. If 
you try
to get the file-handle of a NULL key-ring, it will fail with an error, 
so you
can't modify it or add keys.  Whenever you create a new 
process/UID/session
whatever, it will receive a NULL key-ring reference.  This helps 
security :-D.
This leaves all decisions of policy to a PAM module and some 
configurable
programs.  (Like key-sh or something :-D)

> This seems kinda tricky to implement, _if_ it happens to be desirable.
> Despends on how elaborate the access control is. The default PAG is 
> easy
> enough to keep under a uid key. But one would need to stop processes 
> from
> dropping our session key, right? Or else they could remove it and gain
> access to the uid key. Might be undesirable if there are any 
> applications
> that change uid to root (say), should root have a default PAG with
> interesting tokens attached. Or perhaps I'm just confused about which 
> uid
> is used when. Or perhaps root just needs to be careful.

Most likely you wouldn't attach a key to the UID except for a chrooted 
BIND or
something.  For users, the PAM module would use its internal policy to 
attach
a new session's context to the key-ring used by the other sessions.

> Still the PAG jail isn't for real now, as I store my kerberos tickets 
> in an
> ordinary file owned by myself...

I am unfamiliar with the "PAG jail", can you please explain this 
concept to me?

> Kyle: are you in sync with dhowells on this?

He and I worked out a lot of the concepts for the patch, but I haven't 
talked
with him recently.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------