Thread (24 messages) 24 messages, 8 authors, 2024-07-11

Re: [syzbot] [lsm?] general protection fault in hook_inode_free_security

From: Paul Moore <paul@paul-moore.com>
Date: 2024-07-11 14:06:55
Also in: linux-fsdevel, lkml

On Wed, Jul 10, 2024 at 8:32 PM Tetsuo Handa
[off-list ref] wrote:
On 2024/06/28 3:28, Paul Moore wrote:
quoted
It's also worth mentioning that while we always allocate i_security in
security_inode_alloc() right now, I can see a world where we allocate
the i_security field based on need using the lsm_blob_size info (maybe
that works today?  not sure how kmem_cache handled 0 length blobs?).
The result is that there might be a legitimate case where i_security
is NULL, yet we still want to call into the LSM using the
inode_free_security() implementation hook.
As a LKM-based LSM user, I don't like dependency on the lsm_blob_size info.

Since LKM-based LSM users cannot use lsm_blob_size due to __ro_after_init,
LKM-based LSM users depend on individual LSM hooks being called even if
i_security is NULL. How do we provide hooks for AV/EDR which cannot be
built into vmlinux (due to distributor's support policy) ? They cannot be
benefited from infrastructure-managed security blobs.
As stated many times in the past, the LSM framework as well as the
Linux kernel in general, does not provide the same level of
consideration to out-of-tree code that it does to upstream, mainline
code.  My policy on this remains the same as last time we talked:
while I have no goal to make things difficult for out-of-tree code, I
will not sacrifice the continued development and maintenance of
existing upstream code in favor of out-of-tree code.

-- 
paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help