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

[Tetsuo Handa]

On 2023/10/21 4:52, Casey Schaufler wrote:
> On 10/5/2023 5:58 AM, Tetsuo Handa wrote:
>> On 2023/09/13 5:56, Casey Schaufler wrote:
>>> Create a struct lsm_id to contain identifying information about Linux
>>> Security Modules (LSMs). At inception this contains the name of the
>>> module and an identifier associated with the security module.  Change
>>> the security_add_hooks() interface to use this structure.  Change the
>>> individual modules to maintain their own struct lsm_id and pass it to
>>> security_add_hooks().
>> I came to worry about what purpose does the LSM ID value (or more precisely,
>> "struct lsm_id") is used for. If the LSM ID value is used for only switch
>> {reading,writing} /proc/self/attr/ of specific LSM module's information, only
>> LSM modules that use /proc/self/attr/ will need the LSM ID value.
>>
>> But this series uses "struct lsm_id" as one of arguments for security_add_hooks(),
>> and might be reused for different purposes.
>>
>> Then, BPF-based LSMs (which are not considered as in-tree LSM modules, for
>> only BPF hook is considered as in-tree LSM module) might receive unfavorable
>> treatment than non BPF-based LSMs? 
>>
>> [PATCH v15 05/11] says
>>
>>   Create a system call to report the list of Linux Security Modules
>>   that are active on the system. The list is provided as an array
>>   of LSM ID numbers.
>>   
>>   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.
>>
>> but, at least, name of BPF-based LSMs won't be shown up in lsm_list_modules()
>> compared to non BPF-based LSMs? Then, the calling application can't use this
>> list determine what BPF-based LSM specific actions it might take?
> 
> That is correct. Just as knowing that your system is using SELinux won't
> tell you whether a specific action might be permitted because that's driven
> by the loaded policy, so too knowing that your system is using BPF won't
> tell you whether a specific action might be permitted because that's driven
> by the eBPF programs in place.

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?

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

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) ?



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

Say, an access control implementation consists of two parts; "code" and "data".
The "code" is written by developers and is determined at compile time and is
interpreted by CPU, and the "data" is written by administrators and is interpreted
by "code". The "data" part can be either built-in (determined at compile time) or
loadable (configurable at run-time).

eBPF-based access control implementations (which can be loaded via bpf() system
call after boot) consists of "code" and "data". BPF will remain no-op unless
eBPF-based access control implementations are loaded via bpf() system call.
Thus, I believe that an eBPF-based access control implementation should be
considered as an LSM module (like SELinux etc.)