Re: LSM stacking in next for 6.1?
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. 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.
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.
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...
You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree
code".
Trying to change identifier from name to integer is a serious bug.