Re: capabilities patch: trying a more "consensual" approach

[Crispin Cowan <crispin@novell.com>]

Stephen Smalley wrote:
> On Sat, 2006-09-16 at 00:52 +0200, David Madore wrote:
>   
>> Now, if I understand correctly, the various alloc_security() LSM hooks
>> do not stack well: if I want my module to be stackable after SElinux
>> (and I do), I can't hook task_alloc_security() to create my variable,
>> so I need to store these "cuppabilities" in a globally visible task
>> field.  Do I understand correctly?  How acceptable is this?  (We can
>> assume that 32 bits will be wide enough, so I'm not talking about
>> adding huge amounts of data to the task struct.)
>>     
> No, I think that is a losing strategy, and it defeats the purpose of
> having LSM in the first place.  For now, I'd suggest just _not_
> supporting stacking with SELinux until such a time as you've
> successfully gotten your module merged, then later you can take up the
> best way to support such stacking (whether via direct modification of
> SELinux to enable chaining off of its security structures, or via the
> "stacker" module previously implemented by Serge that lacks a real
> motivating user, although that is contentious).
>   
I mostly agree with Stephen. I agree with both the approach of modifying
SELinux so that its task security blobs chain to yours, and I agree with
the suggestion of letting Stacker do it. I also suggest you consider the
inverse stack of making your module stack with SELinux instead of vice
versa (chain in the opposite order) and I suggest you consider making
your module stack with AppArmor.

The only part I question is why you would need to wait for your module
to start development on any of these approaches. Especially the Stacker
approach.

On that point, now that LSM is staying, and there are a multitude of
modules proposed for mainstream, perhaps it is time to reconsider
merging Stacker. There was a *lot* of effort invested there benchmarking
various schemes. With multiple modules coming in, and stacking a
recurring problem, perhaps we need it now.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes