New LSM hooks

[Casey Schaufler]

On 2/5/2019 10:28 AM, Edwin Zimmerman wrote:
> On Tuesday, February 05, 2019 12:40 PM Casey Schaufler wrote:
>> Full disclosure: This is all about me and my interests.
>> ...
>>
>> 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.

We've achieved rat's nest already. I'm working to untangle it as
part of the stacking work.

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

That would be handy. The documentation would need to cover
the purpose for the hook and how a security module would be
expected to use it.

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

I can't say this makes sense. The binder hooks are only
useful for Android, and requiring Smack or AppArmor hooks
be implemented isn't reasonable. It would be reasonable for
the kernfs hook, as the kernfs hook is a workaround for the
fact that kernfs doesn't use inodes.