Casey Schaufler wrote:
> David Wagner wrote:
> > ... single "int pre_foo();" hook now and later want
> > to support multiple registrants, you may well have to change the
> > interface in a non-backwards-compatible way.
>
> 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?
Crispin
P.S. Casey, would you give your project a name, so I can refer to it in
example lists like this? :-)
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution: http://immunix.org
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Tue Apr 24 2001 - 17:12:40 PDT