New LSM hooks

[Edwin Zimmerman]

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.