Re: linux-security-module digest, Vol 1 #575 - 5 msgs

dwheelerat_private

Greg KH said:
 > As David is implementing a Stacker type module, he is going to have to
 > do exactly the same thing for _all_ hooks that you seem to find
 > so ugly.
 > The sys_security() call is not a special case here.  David just didn't
 > realize that sys_security() needs to return -ENOSYS if that specific
 > module does not want to handle the sys_security() call.

Well, it's more specific.  A module must return -ENOSYS if
(a) it doesn't handle the sys_security() call, or
(b) the call isn't "intended" for it (it determines this after
     looking at passed information; I expect most modules will first
     examine the id passed to see if that is "its" id).
I'll document this assumption.

I can short-circuit sys_security calls if they return something
other than -ENOSYS; after all, I can only return one value,
and I expect only one module to respond to a given sys_security
call, so I can just return in that case.
The weird case is if a valid return
value is -ENOSYS (i.e., the value isn't an error - after all, the
return is simple "unsigned" and it's unwise to assume that it's
necessarily anything more specific than that).
In that case, if -ENOSYS is returned
(but not intended to mean -ENOSYS), the short-circuit can't be
detected.  Then, if a later module fails to
check the id, it might respond to a call not intended for it,
causing havoc.  Clause (b) solves this problem...
since they'd ALL return -ENOSYS for calls not intended for them,
the final computed value is -ENOSYS and the recipient gets the right
valud.   Of course, there's a subtle trap here; if a module
doesn't fulfill item (b) and a return value of -ENOSYS is a valid
value (not an error) for a previous module,
it'll work "almost" all the time until this combined condition shows up.

Since I can live with it, I plan to just carry on and not fight
the battle for an interface change.  But I _really_ _appreciate_
the votes of confidence from others here, and if the others here decide
to add a parameter I will gladly modify the stacking code to use it.

As far as stacking, yes, I _do_ think it'd be appropriate for
most LSM modules to be stackable.  In my mental model, many
administrators using LSM will want to use
a set of "small" modules that check for certain security problems,
followed by a "big" module that does more
complex access control (think SubDomain, LIDS, or SELinux).
Examples of small modules include:
  * A module to prevent certain /tmp attacks
  * A module that prevents turning on regular file execute bits
    ("no new executable files")
  * A module that prevents creating/renaming to certain filenames
    (initial "-", control chars, beginning/ending whitespace).
Yes, you could create a monolithic module that does this, but
it'd be easier to just pipe these along.  Even if you just 2
modules ("prevent common attacks" and "nifty access control model"),
you still need a stacker.  But by allowing multiple stacking modules,
you can allow DIFFERENT people to come up with different ways
to identify and foil common attacks, and maintain them separately.
Thus, an openwall could be combined with a filename checker
and SELinux, all maintained by different people.

Still, in my mind, I would expect no more than 5-20 modules to be
stacked up at runtime.  After that, the various ideas would probably
coalesce into larger modules (for speed & to simplify
administration).  This process might repeat over time
(modules coalesce, and new mini-modules appear as someone else
has a new idea).  At that size (5-20), cycling
through sys_security is annoying but not bad, especially since
I think I've solved the locking issue (no locks for reading!).

--- David A. Wheeler
     dwheelerat_private

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