Re: LSM stacking in next for 6.1?
On Wed, Oct 26, 2022 at 8:02 PM Tetsuo Handa
<penguin-kernel(a)i-love.sakura.ne.jp> wrote:
On 2022/10/27 5:11, Paul Moore wrote:
> On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
> <penguin-kernel(a)i-love.sakura.ne.jp> wrote:
>> On 2022/10/25 19:26, John Johansen wrote:
>>> no, Casey is not. He is trying to find a path forward to get LSM
>>> stacking upstream sooner than later. He has made proposals that
>>> admittedly you have not liked, but he has at least tried to propose
>>> ideas that could work within the insane set of constraints.
>>
>> I'm OK with getting LSM stacking upstream. But changes made based on
>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>> LSM modules at runtime because not all loadable LSM modules will be
>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>> be able to utilize e.g. lsm_module_list system call (or whatever
>> changes made while trying to unshare resources/interfaces currently
>> shared among SELinux/Smack/AppArmor).
>
> As a reminder, the LSM layer, just like the rest of the kernel, has no
> plans to provide any level of consideration or support for out-of-tree
> kernel code. LSMs which are not part of the upstream Linux kernel are
> not our concern here; if they fail to work with the syscall and/or LSM
> stacking changes merged, that should not be considered a blocker to
> upstream development.
>
No. You are misunderstanding.
With all due respect, I understand your point very well, I'm simply
trying to explain to you the position that the Linux Kernel has
historically taken with respect to out-of-tree and in-development
code.
This problem is not limited to out-of-tree and/or
loadable LSM modules. This change prevents new LSM modules from getting upstream
due to a chicken-and-egg problem.
It does *not* prevent new LSM modules from being merged upstream.
It may make it more difficult for out-of-tree modules to remain
out-of-tree, but that is both not a concern of the upstream community
nor is it the concern you are currently describing.
Currently anyone can start writing new LSM modules using name as
identifier. But
you are trying to forbid using name as identifier, and trying to force using integer
as identifier, but that integer will not be provided unless new LSM modules get
upstream.
That is correct. In order to have a LSM identifier token the LSM must
be upstream.
Then, how those who want to write new LSM modules can start writing
LSM modules and
propose userspace changes for new LSM modules? They can't use the identifier unless
their LSM module get upstream, which in turn forces them not to propose interface for
userspace programs, which in turn makes it difficult to get new LSM modules tested
by users, which in turn makes it difficult to get upstream due to "who is using
your
LSM module" question, which in turn makes it difficult to get the identifier...
First, new LSMs generally do not need extensive userspace
modifications; of course there may be some, but when one considers the
entirety of a modern Linux distribution the actual percentage should
be quite small. In addition, it is not uncommon for in-development
LSMs to have a set of privately, i.e. not upstreamed, patched
userspace tools while the new LSM works to get upstream. These
private userspace patches are generally merged after the LSM has been
merged into the kernel.
You are trying to force CONFIG_MODULES=n by just "we don't
care about out-of-tree code".
That is not the goal at all and I would appreciate it if you could
stop slandering the motivations of the LSM syscall effort.
Trying to change identifier from name to integer is a serious bug.
I disagree. One would have a similar problem - userspace
awareness/enablement - regardless of if a name or a token is used.
Ultimately the challenge is getting userspace developers to accept a
change that is not part of the upstream Linux Kernel and thus not
guaranteed under the usual "don't break userspace" kernel API promise.
--
paul-moore.com