On Tuesday, February 05, 2019 12:40 PM Casey Schaufler wrote:

Full disclosure: This is all about me and my interests.

Developers propose new LSM hooks for many reasons. Often,
it's in support of an exotic feature such as Infiniband.
Sometimes it's because someone got clever when they optimized
an otherwise mundane feature and bypassed the usual hooks,
as is being proposed for kernfs. Usually there is a particular
security module (i.e. SELinux) that is targeted for the hook.
In almost all cases a hook is provided for that LSM, but not
for any other. In many cases the developers don't even include
the LSM email list in the discussions. LSM maintainers find
out about the new hooks after the fact.

Prior to 2008, when there was only one LSM, this made perfect
sense. Since then, it's been a regular practice justified by
the notion that it's the LSM maintainer's option to use the
hook or not. That also makes sense in cases where the use is
strictly optional, as it is in binder. It does not make sense,
however, when a core system facility like kernfs is involved.

I get a double whammy on these new LSM hooks. I have to try
to figure out if Smack cares, and if it does, whether to proposed
hook will solve the problem for Smack. Because Smack uses
xattrs and process attributes differently from SELinux there are
often problems with hooks that are provided with only an SELinux
implementation. I also have to work out how the new hook will
work in the stacked security module case. There are some existing
hooks that are a special challenge there, and when a new hook is
proposed that does the same kind of things (e.g. use of secid,
secctx or list of xattrs) without considering the consequences
for other modules.

What do I want, I hear you cry? I want some sanity in the way
LSM hooks are introduced. I want some standards or conventions
on what is appropriate to pass into and out of LSM hooks. I
want push back on special purpose hooks that are required to
fix the deficiencies of a filesystem or bizarre hardware
implementation. I want to stop spending all my time trying to
deal with new, crazy LSM hooks. There are enough old ones to
keep me entertained, thank you very much.

I agree.  We need a roadmap of where we want the LSM infrastructure to go.
Without such a guide, LSM code is going to end up as a rats nest of
confusing, partially implemented, partially supported code.

Here's my suggestion for starters. According to kernel documentation, new 
LSMs must be documented before being accepted.  Perhaps we need a 
similar requirement for LSM hooks.  As I see it, LSMs are security additions,
not functionality patches for the rest of the kernel or for special hardware or
whatever.  Therefore, I also suggest that all new hooks be implemented in 
at least two LSMs before being accepted.

-Edwin Zimmerman

We're about to get a bunch of new LSMs. I don't think that we
can afford to continue with the current "feature A needs a hook
for LSM S" behavior.