Re: Thinking about stacking in LSM: merge registering, add info about field use to security_operations

chrisat_private

* David Wheeler (dwheelerat_private) wrote:
> 
> I don't think that having two _separate_ pairs of operations
> is the best approach.  Why not have a SINGLE pair of operations,
> register_security() and unregister_security(), called by any
> LSM module, that take both the name and the struct security_operations?
> That way any LSM module that registers always calls register_security().
> The "first" module loaded is always the primary security policy
> (until it's unloaded and another takes its place).
> Once a primary module is registered,
> any other LSM module that tries to load would (as always) call the top
> level register_security(), and the kernel would immediately
> detect that it's NOT the primary (since there's already one) and
> call the function defined in the primary's register_security()
> field of its security_operations.
> Primary modules that don't support stacking underneath them can just
> forbid the request, those that support stacking only specific modules
> can permit only those modules, etc.

We talked about this during the inception of module stacking.  While I'm
not opposed to cleaner solutions, we intentionally broke the interface
apart.  It may be important for a module to load _only_ as the primary
module.  If you batch the two stage registration into one function you
either need to include in the function prototype a flag that says "under
no circumstances do I want to be registered as a secondary" or lose the
ability to know where you stand.  I still don't see a compelling reason
to make stacking anything less than very explicit.

> This should simplify the common case of "I have an LSM module,
> how do I register?".  The answer is always "call register_security()".
> This would make it easier to create multiplexor-capable
> modules.  More importantly, it would concentrate most decisions
> about "can these modules be multiplexed together" into the
> primary security module/multiplexor.  In short, rather than
> writing separate "capable of being subordinate" and "capable of being
> a primary" modules, a module can always be both.
> Not all LSM modules can be combined, but it seems to me
> that this decision belongs to the administrator installing the modules.
> 
> Of course, this doesn't mean that any two arbitrary LSM modules
> will get along.  Although there may be other reasons, probably the
> most obvious reason is that some LSM modules may use the
> 'opaque' data fields in certain kernel structures.
> Unless these modules work together and/or share the fields,
> there will serious trouble.   As both an aid to documentation and
> to detect and prevent problems, I think it'd be useful to add
> yet-one-more-field to security_operations, so that an LSM module
> can report on WHICH fields it uses and HOW it uses them.
> To do this, add a field security_operations something like this:
>     unsigned field_usage;
> 
> Then, for each kernel structure where there's an opaque security
> field type, identify if it's "USED" (e.g., the LSM module needs complete
> control) or "SHARED" (shared through some sort of linked-list
> convention not yet defined, though I know it's been discussed)
> by the LSM module as part of the security_operations information.
> 
> Thus, an LSM module might include its declaration of its
> security_operations a value like this for the field_usage value:
>     TASK_SECURITY_FIELD_USED | LINUX_BINPRM_SECURITY_FIELD_USED |
>     INODE_SECURITY_FIELD_USED | FILE_SECURITY_FIELD_USED

This seems like the kind of thing that adds complexity and could easily
be out of date.  I prefer keeping it dead simple.  The right thing for a
multiplexor to do is simply always assume there could be collision in
the blobs and account for it properly.

thanks,
-chri
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module