linux-kernel - Re: [PATCH 2/3] lsm: introduce security_lsm_manage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <120954c2-87b7-4bda-958b-2b4f0180a736@canonical.com>
Date: Thu, 8 May 2025 01:29:02 -0700
From: John Johansen <john.johansen@...onical.com>
To: Paul Moore <paul@...l-moore.com>,
 Maxime Bélair <maxime.belair@...onical.com>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
 linux-security-module@...r.kernel.org, jmorris@...ei.org, serge@...lyn.com,
 mic@...ikod.net, kees@...nel.org, stephen.smalley.work@...il.com,
 casey@...aufler-ca.com, takedakn@...data.co.jp, linux-api@...r.kernel.org,
 apparmor@...ts.ubuntu.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook

On 5/7/25 13:25, Paul Moore wrote:
> On Wed, May 7, 2025 at 6:41 AM Tetsuo Handa
> <penguin-kernel@...ove.sakura.ne.jp> 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.