Message-ID: <f1608a96-e18d-45a8-84c9-8195a9bd9458@schaufler-ca.com>
Date:   Sun, 29 Oct 2023 11:00:39 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        paul@...l-moore.com, linux-security-module@...r.kernel.org
Cc:     jmorris@...ei.org, serge@...lyn.com, keescook@...omium.org,
        john.johansen@...onical.com, stephen.smalley.work@...il.com,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        mic@...ikod.net, Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v15 01/11] LSM: Identify modules by more than name

On 10/29/2023 3:57 AM, Tetsuo Handa wrote:
> 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 .

No, I stand by the description as written.

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

You are correct. If I thought there was the remotest possibility
of that, I wouldn't have used it as an example.

If Smack isn't enabled there's no point in running the Smack testsuite.
If SELinux isn't enabled there's no point in running the SELinux testsuite.
If SELinux isn't enabled there's no reason to invoke SELinux userspace features.

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

Believe me, that's way down on the list of userspace issues with using Smack and
SELinux together in a meaningful way.

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

That is correct.

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

That's already true. You have to understand all sorts of factors, like SELinux policy,
Smack rule sets and AppArmor policy definitions. Then there's netfilter configuration.


>>>> 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 BPF program set is no different from the SELinux policy in this regard.
It's completely user defined, and out of the kernel's control. I seriously
doubt that you want an ID for "SELinux reference policy 4.3.2 with Infiniband"



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

OK.

Powered by blists - more mailing lists