Comingling

dwheelerat_private

Crispin Cowan <crispinat_private> said:

> Casey Schaufler wrote:
>
> > Life will be much easier if systems have a single policy.
> > Nested, stacked, heaped, and comingled policies leave end
> > users with many questions and support organizations with
> > few answers. I you must have multiple registered policies,
> > how about a seperate module which is the registable policy
> > policy module? That way poicies which wish to be free from
> > interference from other modules can be.
>
> I'm in an agreeable mood today :-)
>
>    * I agree with Casey that comingling policies is hard, and likely to
>      produce a mess.
>    * I agree with Seth that having multiple modules is going to be
>      necessary in practice, esp. if one of the modules is Capabilities.
>    * I agree with Greg that it's better to make the first module loaded
>      be the multiplexor, rather than building a separate multiplexor
>      module, and/or requiring every module to be able to multiplex.
>
> Basically, I want "teams" of modules to be able to cooperate if they were
> designed to cooperate, but not require arbitrary collections of modules
> to necessarily be able to cooperate:
>
>    * SubDomain and CryptoMark need to be able to cooperate.
>    * Capabilites need to be able to cooperate with everyone.
>    * It is not necessary that SubDomain, LIDS, and Janus be able to
>      cooperate.
>
> Does that make sense?

Yes - in particular, I agree that there must be a way to support
multiple security modules.  Not so much so that "major modules"
(like Janus and SE/Linux) be able to cooperate, but so that you can
add additional "smaller, single-purpose" modules.

I believe there's a large set of special-purpose modules that could
and would be written, once there's a way to hook them in.
In particular, host-based intrusion detection systems (IDSs) would
want the same sort of hooks, and these hooks would give them the
power to enforce certain policies when triggered.  You'd want to
be able to add general-purpose policy model as well as the IDS.

The "multiplexor" sounds like the most efficient and flexible approach.
Each hook only has to call one module, and different people could
implement different multiplexors.  Presumably this means that there will
need to be a standard kernel module API so that security modules can
register with the selected multiplexor (or hook in directly, if they're
the first one loaded).  I would expect there to be a "standard" multiplexor
that came with the kernel - it could just invoke all the other modules
for that hook & only accept things if they all passed.

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