stackable modules

blockdevat_private

I've been lurking for a month.  This message will no doubt
demonstrate that a month was not enough.

For stacking modules, it seems that the multiplexor approach
is much cleaner and more powerful than a chaining approach.
It appears (from language like, "pass it down the chain")
that the original recommendation was for a sort of linked
list of modules- this, of course, will cause hell when the
admin decides to unload a module in the middle of the chain,
particularly if there is no way to pass the requirements
of that module around (so as to rip the appropriate stuff
out of the security blob).  It also offers no clear way
to add a module once the chain has been established.

My (probably naīve) question is, "why must the LSM be aware
of this at all?"  Not being a kernel hacker of any great
talent or experience, I've always sort of thought that a
module can do anything any other kernel code can do.  It
may put a significant burden on the poor sod who writes the
multiplexor, but why would it be particularly difficult for
the multiplexor module to detect when another module attempts
to register(), add the appropriate cruft to the blob, and
get on with life?  Would it require the multiplexor to unregister
and re-register?  Would that be really really bad?  Why is
the sky blue?

I've also sort of always held the notion that the whole
point of a kernel module interface is to allow for simple
and quick runtime configuration of a kernel.  That is, the
whole idea seems to be building small (kernel-space) tools
for small jobs, and combining them to suit a need.  Aside
from some small performance gain in not having to follow
hooks around, it's not clear to me what advantage a giant,
monolithic kernel module has over, say, a giant, monolithic
kernel.  That LSM hooks should support as many modules as
require them without too much fuss _seems_ pretty central.
What am I missing?

  -- Matt

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