Re: [RFC] [PATCH] Stacking through chaining (v3)

From: Valdis.Kletnieks@private
Date: Tue Nov 30 2004 - 09:57:10 PST

On Tue, 30 Nov 2004 11:00:36 CST, "Serge E. Hallyn" said:

> Agreed, we could consider getting rid of mod_reg_security altogether.  But
> right now I'm just suggesting keeping mod_reg_security, and getting rid of
> mod_unreg_security.  The module can control how it's loaded, but there's no
> point (I can see) controlling how it's unloaded.

How many of the existing LSMs permit building as modules, but don't have any
code to trap for attempts to rmmod itself? :)

We *do* need a "mod_unreg_security()" call that has the semantics of "remove
my list of hooks from the appropriate structures".  I don't think it has any
need to be different for primary/secondary/chained if the code in unreg_security()
is able to figure out by itself how the module was registered and undo it.

For that matter, are there any existing cases where a module *cares* if it's
primary or secondary (as in "returns different results based *only* on its own
status as primary/secondary, with *NO* regard as to what the "other" module

I can see where an LSM *might* want to do something like "return A if we
also have SELinux loaded, but do B otherwise".  For instance, we recently had
a discussion about an OpenWall-ish LSM I have, where we decided that most of
the function was also doable in SELinux - in a case like that, my code could
very well want to defer to SELinux if present, but apply its check otherwise.
Testing for if my code is primary or secondary is *wrong* - the fact I'm
a secondary is *not* identically equal to selinux running - I *could* be
secondary to a LIDS or something else....

That raises a performance question - if a "is FOO loaded" function is
provided, can we do it with very low overhead (so it's called each time),
or do we need to provide a "FOO is loading/FOO is unloading" notification
to other LSM's that might care?

This archive was generated by hypermail 2.1.3 : Tue Nov 30 2004 - 09:57:50 PST