Re: In-kernel Authentication Tokens (PAGs)

[Chris Wright <chrisw@osdl.org>]

* Kyle Moffett (mrmacman_g4@mac.com) wrote:
> On Jun 12, 2004, at 16:53, Chris Wright wrote:
> > Actually that's not the case.  The UID is currently insufficient to
> > describe the security domain that a process is running in.  The whole
> > of the LSM infrastructure is designed with this in mind.  So somehting
> > like SELinux may enforce a security domain change (w/out a UID change)
> > across an execve() of pagsh.  I was simply trying to ascertain if you
> > were storing this within task->user which I think would be wrong.
> 
> Ahh, ok, I myself have no experience with LSM, so there will likely be 
> some
> need to change my implementation.  Currently the only field that I add 
> to
> existing structures in the kernel is a pag field in the task_struct.  
> PAG
> structures themselves need some way of determining if the calling task
> is in the same "grouping" as a stored "grouping" within the PAG.  My
> implementation uses UIDs, but I would be very glad if you could tell me
> what I should use instead.  I need some kind of structure or pointer 
> that I
> can embed within a PAG and a token, and some kind of equality test.

Typically, objects that LSM cares about include a pointer to opaque
data (security blob) which describes the security domain for the object.
See task->security as an example.  It's not clear to me if task->security
is sufficient and you only need a back pointer to the task or if each
PAG needs it's own security blob.

> The other thing that needs to be implemented is some kind of limit that
> restricts how many PAGs/tokens and how much memory can be allocated
> in the kernel per user and per process.  Do you have any information on
> where would be the best place to store that information?

Sounds like an extension to rlimits.  The counters could be stored in
->user to limit the userwide number of tokens.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net