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

[Kyle Moffett]

On Jul 14, 2004, at 14:21, David Howells wrote:
> I would very much advise against this... otherwise you could end up 
> with a
> kernel vs userspace deadlock very easily. Furthermore, my current patch
> controls read access using a spinlock only - this means that stuff in
> interrupt context can access keys; I think it'd be unwise to do 
> otherwise.

I'm using 2 levels of locking, a kernel-side one and a user-side one.  
The goal
of the user-side one is _only_ to prevent other _user_ processes from 
using
the key while one process is atomically (To userspace) performing 
actions on
it.  The user-space "lock" will just be another member in the struct 
that
describes the type of lock and the process and file-descriptor it is 
tied to.  The
only truly atomic in-kernel lock (a per-key spinlock) is held just long 
enough
to read or modify the key.

> Have you looked at the locking stuff the VFS does? It finds its way 
> into all
> sorts of nooks and crannies because it has to make sure locks are 
> discarded
> when their owner goes away - whatever "owner" means to the system.

User-space "references" to keys in my (incomplete) patch are 
file-descriptors,
so I need to keep track of those anyway (They control a ref-count 
increment).
Sys-calls that allow user-space to access keys would just spinlock the 
kernel
keyring, then if there is already a user-space lock owner, just put 
themselves
on a queue to be woken up when it becomes free.  If it isn't locked, 
they will
just maintain their spinlock and do their modification.

The only time you need to check for the user-side lock is from user 
context,
it doesn't have meaning at any other time.  I don't care if something 
inside of
the inherently privileged _kernel_ needs to read or modify a key 
atomically
during an interrupt, kernel code is generally carefully written enough. 
  I'm
just worried about locking out malicious processes.

> I think you don't really need locking anyway. You just have to be 
> aware that
> what you're dealing with may change under you.

I am worried about the potential security implications of a privileged 
daemon
working with keys while an unprivileged process fools around with them.

>> This leaves all decisions of policy to a PAM module and some
>> configurable programs.  (Like key-sh or something :-D)
>
> I think that's probably a good idea... now we just have to sell Linus 
> on it.

So far it's just been the easy part :-D

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