On 5/7/25 03:40, Tetsuo Handa 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; use of filename helps restricting which type of policy can be manipulated by which process.
That is fine. But curious I am curious what the interface would look like to fit TOMOYO's needs. I look at the current implementation as an opening discussion of what the syscall should look like. I have no delusions that we are going to get something that will fit all LSMs but without requirements, we won't be able to even attempt to hash something better out.
