[PATCH v15 01/11] LSM: Identify modules by more than name

[Tetsuo Handa]

On 2023/10/21 23:11, Casey Schaufler wrote:
>> If the system call returning LSM ID value for SELinux but does not tell
>> the caller of that system call whether a specific action might be permitted,
>> what information does LSM ID value tell?
> 
> It tells the caller that the LSM is active on the system. That's it.
> Just like reading /sys/kernel/security/lsm.

Then, the

  The calling application can use this list determine what LSM
  specific actions it might take. That might include choosing an
  output format, determining required privilege or bypassing
  security module specific behavior.

part should be removed from the description. Instead, the description should
emphasis that the numeric LSM ID values are there in order to allow
identifying what LSM modules are active without interpreting string LSM names
in /sys/kernel/security/lsm .



>> What does "choosing an output format", "determining required privilege",
>> "bypassing security module specific behavior" mean? How can they choose
>> meaningful output format, determine appropriate privilege, bypass security
>> module specific behavior (if the only information the caller can know from
>> the LSM ID value were what LSMs are enabled) ?
> 
> If Smack and SELinux not enabled on the system there is no point in
> setting up a netlabel configuration, for example.

I know nothing about netlabel. But can userspace make such assumption from
this granularity? For example, if TOMOYO and AppArmor start supporting
netlabel configuration, your assumption

  If Smack and SELinux not enabled on the system there is no point in
  setting up a netlabel configuration

becomes no longer true. It is also possible that a new LSM implementation
obtains an LSM ID for that LSM, and starts supporting netlabel configuration
some timer later. I don't know if we come to the point where we can enable
SELinux and Smack at the same time. But when it becomes possible to enable
SELinux and Smack at the same time, the userspace might have already written
code based on current situation that netlabel configuration are exclusive. Then,
someday starting to return both LSM ID for SELinux and LSM ID for Smack might
confuse userspace.

Thus, it might be safe to determine what LSMs are active from the LSM ID values
returned from the system call. But it is not safe to assume what functionality
is active (e.g. netlabel configuration is interpreted) from the LSM ID values
returned from the system call.

If you want to allow userspace to make such assumption using the system call,
the granularity the system call returns needs to be what access control mechanism
(not only LSM modules but also eBPF-based access control mechanisms) hooks which
LSM hooks. More information than interpreting string LSM names in 
/sys/kernel/security/lsm will be needed.

> 
>>> I wish we could stop people from saying "BPF-based LSM". BPF is the LSM. The
>>> eBPF programs that implement a "policy" are NOT a LSM. There needs to be a
>>> name for that, but LSM  is  not  it.
>> My understanding is that "BPF is not an LSM module but infrastructure for using
>> LSM hooks".
> 
> As BPF is implemented as a LSM I suggest your statement is incorrect.

Enumerating only LSM modules are not useful. "ID for access control mechanisms
that can be controlled via LSM hooks" will be needed.

> 
>>
>> The patch description lacks relationship between LSM ID value and data.
>> In other words, why LSM ID values are needed (and are useful for doing what).
>> If the only information the caller can know from the LSM ID value were
>> what LSMs are enabled (i.e. the content of /sys/kernel/security/lsm ), why
>> bother to use LSM ID values? (Yes, integer comparison is faster than string
>> comparison. But that is not enough justification for not allowing out-of-tree
>> LSMs and eBPF-based access control mechanisms to have stable LSM ID values.)
>>

I conclude that LSM ID values are pointless and are NOT needed.