Re: Willing to change LSM so secondary defaults correct

dwheelerat_private

The basic issue is that clearly, "someone" is in charge.
In my mind, the primary module should make ALL
the mixing decisions, e.g., do I want the capabilities module in, or not?
Before my patch, if owlsm was a secondary module, the primary
module DID NOT get to make the decision - the owlsm module ALWAYS
called capability, whether you wanted it to be called or not.

I think that's wrong. I think the primary should ALWAYS make the final
decision, period, and the secondary should let the primary decide.

Now, what happens if a primary module really DOES want
to call capability also?   The primary module _could_ support a linked
list of secondaries (i.e., also be a stacking module!!).
The primary could also say "sorry, if you want that, you need to use
the stacking module".  This latter approach is probably the easiest
to implement.  However, let's mentally explore alternatives.

If you want something in-between for primaries
that don't want to manage a list of secondary modules, here's one idea:
"merger" functions. Just create 2 new functions, callable by primaries, that
lets them merge the security_ops of a module with dummy or capability,
so they can efficiently handle this special case.

For example, a simple primary
could call dummy by default, unless the capability module
was loaded under it.  Then the primary would
handle requests to register a secondary like this:
  if (the requestor is capability or capability is already the secondary)
      merge_capability_security_ops_and_other_secondary()
  else
      merge_dummy()
If the primary calls capability by default, registering is even easier:
  try_to_merge_capability_security_ops_and_other_secondary()
This means that you don't need complicated signaling mechanisms between
the secondary and primary; the primary is always in control.
The merge function could be part of LSM itself (in the capability module).
A few lines of code in typical primaries - not bad at all, if you believe
that most will want to quietly call the capability module too.
When removing, you'd have to remove the other module or add special
case code (probably not worth it in this case).
This means you don't need to walk a linked list.

If that's not flexible enough (e.g., you want to use "capability2"),
then use the stacker module to get exactly what you want.

It would mean that typical primaries only need a few lines of code to
efficiently handle a common case (e.g., "SELinux + OWLSM + Capability"),
and fancy approaches ("SElinux + Owlsm + another_module + capability2") are
possible by using the "stacker".

Of course, if this is all too complicated, there's a simple approach:
MAC modules could support only the capability modul.  For any
other mixing, you need to use a stacker.  That simplifies code, but
increases the need for a stacker.

Now, let's walk through the cases:

Crispin Cowan wrote:

> David Wheeler wrote:
> 
>> However, before doing so, I want to hear any comments.
>> If people often want to mix in the capability module with another
>> secondary module when they have a single child,
> 
> 
> Single child; hmmm. Does that mean "stacker + one functional module"? Or 
> "stacker + capabilities + one other module"? I expect the common cases 
> to be:
> 
>   1. capabilities only: oblivious users who don't do anything to
>      enhance kernel security, and just load up the defaults.

Unchanged, still works.

>   2. capabilities + OWLSM: nearly oblivious users who want to just add
>      the "zero management" security of OWLSM.

Unchanged.  Loading owlsm as the primary automatically calls capability
as well, for example.

>   3. capabilities + OWLSM + MAC: where "MAC" is one of SELinux, LIDS,
>      DTE, or SubDomain, etc. Users taking active steps to enhance
>      security with MAC.

By loading "MAC" first, then owlsm, then capability (or the other order)
you get this if the MAC module implements the approach above and defaults to
dummy.  If MAC defaults to capability, then the insmod capability is optional.

You can, of course, do this with stacker.

>   4. OWLSM + MAC: as above, but people who think capabilities suck :-)

By loading "MAC" first, then owlsm (presuming that "MAC" defaults to dummy).

If you use the "stacker", you can do all that, though I would order it as
"OWLSM + MAC + capabilities".  Load Stacker, and now load
load "MAC + OWLSM + dummy" or "MAC + OWLSM + capability2".
In short, you CAN do it.

>   5. MAC only: as above, but think that OWLSM sucks too.

Just load MAC.  If MAC calls capability when it's a primary, then you
need to keep it from being a primary --- e.g., load stacker and then MAC.

> 
> In the cases where there is only one functional module, we can skip 
> stacker. There are two cases with two modules (#2 and #4) and only one 
> of them involves capabilities.
> 
> Speak up if you think I've omitted an important case.
> 
> WireX will probably go with #3 or #4, plus some additional modules of 
> our own. Get your own magic 8 ball to predict the order of popularity :-)
> 
> Crispin
> 

-- 

--- David A. Wheeler
     dwheelerat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module