I just wanted to add that I'm _delighted_ to see that
work on stacking LSM modules has continued.
My thanks to all of you for carrying that work on.
Serge Hallyn wrote:
> Digsig is quite orthogonal to SELinux and capabilities, so I don't think
> there would be any reason why it couldn't be stacked through stacker.
> Valdis wanted his module to behave differently based on whether SELinux
> was loaded. This isn't quite the same as his results depending on
> SELinux results, though, so it might still be loadable through stacker.
There's another alternative, too. Instead of making
the module itself vary its behavior, you could simply write
a small script that:
(1) checks for SELinux
(2) select the "right" digsig module, or pass a parameter, that
varies depending on (1).
Serge Hallyn continued with:
> Valdis, Joshua, Makan, am I wrong about that? I don't want to stop
> anything from working, but if possible I think that drawing the line
> between (1) stacking two independing LSMs and (2) loading two
> cooperating LSMs would be useful.
Makan Pourzandi replied:
>Regarding the second case, it's reasonable to believe that some people
>would always have their own "specific" modules that could never get into
>main stream Linux (and SE Linux). ...
>I believe what I try to
>say is that the second case can be an enabler or a catalyzer for
>developing new security functinality for Linux in general.
That's in fact the reason I was very interested in a "stacker".
There are a number of specialized checks that I'd like to be able
to add, both to myself and to redistribute to others for
testing/experimentation/local use for gaining experience.
For example, I'd like to create a module that doesn't allow files
to be created unless they match (or don't match) certain patterns,
e.g., must begin and end with non-whitespace, may not
contain control chars, cannot begin with "-", must be
valid shortest-form UTF-8, etc. Another module (like openwall)
might forbid certain patterns suggesting bad tempfile use,
and so on.
Clearly you can do anything by modifying the kernel.
But few people understand or are willing to recompile & install
a whole new kernel. And I'd like to support a number of
these small specialized-function LSMs, so that different people
can create very narrow and specialized checks, and other
people can mix & match them.
Indeed, I suspect there would be many of these small LSM
modules that don't need to store any special state at all
on processes, etc. (like my filename checking example).
>Well, back to
>the subject, in this latter case the composition policy "operation
>allowed if all modules allow it" seems to be the best choice.
I agree.
--- David A. Wheeler
This archive was generated by hypermail 2.1.3 : Fri Dec 17 2004 - 14:30:34 PST