[PATCH v4 15/23] LSM: Specify which LSM to display

[John Johansen]

On 6/28/19 9:15 AM, Casey Schaufler wrote:
> On 6/28/2019 7:45 AM, Stephen Smalley wrote:
>> On 6/26/19 3:22 PM, Casey Schaufler wrote:
>>> Create a new entry "display" in /proc/.../attr for controlling
>>> which LSM security information is displayed for a process.
>>> The name of an active LSM that supplies hooks for human readable
>>> data may be written to "display" to set the value. The name of
>>> the LSM currently in use can be read from "display".
>>> At this point there can only be one LSM capable of display
>>> active.
>>
>> IIUC, presently, at the end of the entire series,
>>
>> 1) Any process can change its display attribute to any enabled security module, and no security module can veto that change.
> 
> That is correct. If a security module could hoard the display it
> could prevent user space from functioning in a multiple module
> environment.
> 

It should be noted that this is also just for legacy, we agreed
last year that smack and apparmor would move to new none shared
interfaces by default, and ideally other LSMs would as well.
Smack has already added its process dir and apparmor has its
in apparmor-next

The display LSM allows for the current interfaces to be used
in a stacking situation for things like LSM in legacy container.

>> 2) The display attribute is inherited across fork and exec, even execs that change credentials, and again no security module has control over the inheritance of this attribute.
> 
> Also correct. Scripts don't work otherwise.
> 
>>
>> 3) Setting the display attribute affects more than just the contexts read or written by the process itself:
>> - Contexts reported in audit logs,
>> - Contexts passed across binder (generated in sender context, delivered to receiver),
>> - Contexts passed to NFS servers for new files,
>> - Contexts returned by NFS servers for existing files,
>> - Netlink-related contexts (?possibly generated in sender context rather than receiver context?),
>> - This list may not be complete.
> 
> Any of which can be changed should a more rational behavior be proposed.
> One possibility is to use lsm='value',lsm='value' encoding for internal
> communications, but there's been considerable resistance to anything
> like that.
> 

This is the part of the patchset that I am least happy with but
it is a hard problem, and so far using display has been the only
option that has been even sort of agreed to.


>> 4) A security_secid_to_secctx() in one process' context (e.g. sender) or with one display value followed later by a security_secctx_to_secid() call in a different process' context (e.g. receiver) or with a different display value may ask a different security module to perform the reverse translation of the context than the forward translation.
> 
> Do you have an example of where this might happen?
> Contexts are rarely used within the kernel. The usual
> behavior is to generate them, send them out to user space,
> and delete them. They get cached in some networking code,
> but not in cases where more than one (existing) security
> module will ever use them. Binder may be an exception, but
> only SELinux (currently) supports binder.
> 
> 
>> Is that correct?  If so, it seems problematic.
> 
> Balancing backward compatibility with new behavior is hard!
> What would you suggest for audit logs? Should we put all LSM
> data in every record?

If we could it would be better, but again how to do it. Every
option presented has been rejected.

> Is NFS a concern for anyone not using
> SELinux?
> 
Yes. Just because it isn't currently used doesn't mean it isn't
a concern or desired. 

> There is no user space that uses display, and it's going
> to take some time to work out all the kinks before we even
> think about teaching systemd about it.
> 

I'm not even sure we want to teach systemd et al. about it,
it would be far better to teach them about
  /proc/*/attr/{smack,apparmor,...}/*


But yes its going to take time to get the userspace updated.