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

dwheelerat_private

Chris Wright wrote:

> * 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(), ...
> 
> 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.

I definitely believe in warning/protecting admins from
accidentally making misconfigurations.  But if an
administrator KNOWS that the given module can be stacked
underneath some other module, then let 'em.
A flag would make some sense, if that's critical as a warning.
However, it's easy to imagine "small" modules
(e.g., "don't allow certain /tmp operations") that can
be stacked with "large" modules (e.g., SELinux) even though
the "big" module author didn't make room for them, and
allow for a stacking module (e.g., "require all") to combine them.

The problem that I see is that right now, what exactly
does a module writer call when they're inserted?
Do they call register_security(), or mod_reg_security()?
It seems better to say "always call register_security()".
If you think it's critical for a module to say
"I prefer not to be stacked", then I guess that could be
incorporated in the call (directly or indirectly via security_ops).
That way, all modules are in theory stackable as long
as the higher-level stacking modules properly account for
their behavior.

In short, is it the job of every LSM module to limit stacking by
the primary module, or is it the primary stacking module's job
to figure out what can be stacked and how?
I suggest that individual LSM modules shouldn't worry about
the stacking issue at all (where possible) if they aren't
the primary module.   Said another way, LSM modules should leave the
entire stacking problem _completely_ in the hands of the
primary module if they aren't the primary module.
After all, an author of a given LSM module can't anticipate
all possible stacking combinations - so let's not make modules
assume that all stackings are illegeal.
If someone wants SELinux to be
the non-primary module - and thus stacked under some other module -
let it be the primary module's problem to figure out how
to handle things.

>> 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.

It's not clear to me that a multiplexor could really
"account for it properly", since it doesn't have the
information it needs to detect this problem.  Actually,
I don't think a multiplexor by itself could really
"deal" with the problem; it's not going to swap data field
values around on every hook call!  Instead, I view this
as a way to document usage and detect possible problems.

Out-of-date code
is always an issue, but I don't think it'd be a big deal
in this case, since I would expect that an LSM module
would only rarely start using new data fields it hadn't
used before once it's ready for prime time.

I do agree that it adds some complexity, which may not
be worth it.  I think this field is less important, and
could added later more easily than changing the
registration interface.

--- David A. Wheeler
     dwheelerat_private

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