Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: John Johansen
Date: Sun May 11 2025 - 07:20:58 EST
On 5/9/25 03:26, Mickaël Salaün wrote:
On Thu, May 08, 2025 at 09:54:19AM -0700, Casey Schaufler wrote:
On 5/8/2025 1:29 AM, John Johansen wrote:
On 5/7/25 13:25, Paul Moore wrote:
On Wed, May 7, 2025 at 6:41 AM Tetsuo Handa
<penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
On 2025/05/06 23:32, Maxime Bélair wrote:
diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
index dcaad8818679..b39e6635a7d5 100644
--- a/security/lsm_syscalls.c
+++ b/security/lsm_syscalls.c
@@ -122,5 +122,10 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user
*, ids, u32 __user *, size,
SYSCALL_DEFINE5(lsm_manage_policy, u32, lsm_id, u32, op, void
__user *, buf, u32
__user *, size, u32, flags)
{
- return 0;
+ size_t usize;
+
+ if (get_user(usize, size))
+ return -EFAULT;
+
+ return security_lsm_manage_policy(lsm_id, op, buf, usize,
flags);
}
syzbot will report user-controlled unbounded huge size memory
allocation attempt. ;-)
This interface might be fine for AppArmor, but TOMOYO won't use this
interface because
TOMOYO's policy is line-oriented ASCII text data where the
destination is switched via
pseudo‑filesystem's filename ...
While Tetsuo's comment is limited to TOMOYO, I believe the argument
applies to a number of other LSMs as well. The reality is that there
is no one policy ideal shared across LSMs and that complicates things
like the lsm_manage_policy() proposal. I'm intentionally saying
"complicates" and not "prevents" because I don't want to flat out
reject something like this, but I think there needs to be a larger
discussion among the different LSM groups about what such an API
should look like. We may not need to get every LSM to support this
new API, but we need to get something that would work for a
significant majority and would be general/extensible enough that we
would expect it to work with the majority of future LSMs (as much as
we can predict the future anyway).
yep, I look at this is just a starting point for discussion. There
isn't going to be any discussion without some code, so here is a v1
that supports a single LSM let the bike shedding begin.
Aside from the issues with allocating a buffer for a big policy
I don't see a problem with this proposal. The system call looks
a lot like the other LSM interfaces, so any developer who likes
those ought to like this one. The infrastructure can easily check
the lsm_id and only call the appropriate LSM hook, so no one
is going to be interfering with other modules.
We may not want to only be able to load buffers containing policies, but
also to leverage file descriptors like Landlock does. Getting a
I am not opposed to a syscall that leverages file desriptors like landlock
but that would be a different syscall with different semantics, and
something for an lsm that wants that semantic to introduce.
property from a kernel object or updating it is mainly about dealing
with a buffer. And the current LSM syscalls do just that. Other kind
of operations may require more than that though.
sure but they don't do it for the semantic of loading/managing policy.
I don't like multiplexer syscalls because they don't expose a clear
semantic and can be complex to manage and filter. This new syscall is
kind of a multiplexer that redirect commands to an arbitrary set of
kernel parts, which can then define their own semantic. I'd like to see
a clear set of well-defined operations and their required permission.
Even better, one syscall per operation should simplify their interface.
I am not opposed to that approach. This can be multiple syscalls. Its
a v1 to try and see if we can come to any agreement on a set of semantics