Re: lsm stacker

From: David A. Wheeler (dwheeler@private)
Date: Thu Jun 30 2005 - 08:36:41 PDT


Stephen Smalley asked:
 > Do you really want to encourage proliferation of ad-hoc special purpose
 > LSMs?

Yes, I think it's a good idea, but perhaps
my mental model of "typical stacking use" is very
different from yours.

I expect that most people will choose at most one
large, general-purpose access control model like SELinux, which
defines a broad access control model covering all
circumstances.  And I expect there will be very few such
general-purpose models; "traditional Unix" and "SELinux"
seem to be the two most popular right now in LinuxLand.

But then there are various activities that can create
a vulnerability, or help lead to such a state, that you want
to prevent, yet aren't easily covered by a traditional model.
For example:
* Limit filenname creation to certain formats (e.g., forbid
   leading "-", forbid control characters, require UTF-8 format),
   because some filenames can be easily abused to cause vulnerabilities.
* Forbid following tempfiles/symlinks in certain combinations,
   like OpenWall does, because they can lead to race conditions
* Detect sequences that appear to be, in combination, an attack &
   prevent them.  E.G., an Intrusion Prevention System.

Nobody will agree on exactly what that set should be, but that's
perfect for loadable stackable modules... just load the
set that describes what YOU want to prevent, given your
expected use of the system.  Different expected use, different
set of modules.


 >  That would seem to lend itself toward:
 >- fragmentation of already scarce security resources that could instead
 >be working toward a common unified solution,

Quite the reverse, I believe.  A single LSM
that covers SELinux-like mandatory access controls,
illegal filename patterns, handles OpenWall symlinks,
detects sequences that are malicious, and so on would be
completely unwieldy.

Instead, break the problem down.  Since many of the modules
I envision are more 'detect specific kinds of problems', exactly
what you have to detect is very system-dependent.

 >- most LSMs remaining out of tree,

I doubt it; people will want them reviewed, which will
push them into the tree.

 >- no real review of how these LSMs compose (or should not compose) by
 >people who might be capable of evaluating them (most sysadmins won't be
 >able to perform such analysis on their own),

Composition in the _general_ case is extremely hard.
But composition in the special case is often much easier.
In particular, if you only forbid activities that should
never be allowed to occur, there's no loss.

The risk is that by forbidding to allow some activity, you
create a vulnerability.  E.G., sendmail couldn't drop privilege
in one model, and thus ran vulnerability when it shouldn't have.
This is a real risk, but it's also a risk to allow other
dangerous activity, so trades & thought are necessary.

 >- no stable kernel security model or API due to variances in the set of
 >LSMs present in any given kernel and thus no effective leveraging of any
 >specific security model or API by upstream applications that want to be
 >portable.

I don't think this dire circumstance needs to occur.


--- David A. Wheeler



This archive was generated by hypermail 2.1.3 : Thu Jun 30 2005 - 08:48:49 PDT