New LSM hooks

[Stephen Smalley]

On 2/6/19 12:24 PM, Casey Schaufler wrote:
> On 2/6/2019 5:20 AM, Stephen Smalley wrote:
>> On 2/5/19 8:11 PM, James Morris wrote:
>>> On Tue, 5 Feb 2019, Paul Moore wrote:
>>>
>>>> I believe that will always be a problem, no matter what we do.  The
>>>> point I was trying to make was that everyone, especially the
>>>> maintainers, need to watch for this when patches are posted and make
>>>> sure the patch author posts to the LSM list in addition to any of the
>>>> relevant LSM specific lists.
>>>
>>> Right, and there is no way a new LSM hook should ever be added to the
>>> kernel without review and ack/signoffs from folks on the LSM list
>>> (especially those who are maintainers of in-tree LSMs).
>>>
>>> Casey, do you have any examples of this happening?
>>
>> Most of the times I've seen that it has come from vfs folks or other subsystems as part of some major reworking of that subsystem rather than from security module developers, e.g. the mount hooks overhaul.
> 
> David Howells did contact me directly on the mount hook
> changes well in advance. I'm more concerned with special
> purpose hooks like we have for binder, kernfs, nfs, tun,
> Infiniband and bpf. I'm not saying that we never need to
> provide hooks with a single user, but you do have to
> wonder about security_ismaclabel().

binder is an IPC mechanism, so just like all the other IPC mechanisms, 
we needed hooks to mediate it.  No different than having hooks for 
System V IPC or Unix sockets. If LSM were a proper abstraction layer 
like the Flask architecture or even the BSD MAC framework, then we'd 
have some general purpose access control interface with a small number 
of entrypoints to invoke, but instead we just push all of that behind 
the LSM interface.  I wasn't an advocate for the LSM approach at the 
time but it is what was adopted and we have to live with it.

kernfs doesn't follow the usual rules for inode setup, so we have to 
play by its rules. Not our choice to make, and there is a reason why 
kernfs is the way it is.

NFSv4.2 chose to support MAC labels as a first class citizen rather than 
just xattrs (and there was a reason for that too), so we need a 
different path for getting and setting those labels.

And so on for tun, infiniband, and bpf.  Remember that LSM by design 
does nothing more than expose the kernel objects and operations to the 
security modules and leaves it up to the module writer to do everything 
else.