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: <1b01ccd0-5a1b-4b34-bbe4-13ee3b73292d@canonical.com>
Date: Sun, 11 May 2025 04:20:42 -0700
From: John Johansen <john.johansen@...onical.com>
To: Mickaël Salaün <mic@...ikod.net>,
 Casey Schaufler <casey@...aufler-ca.com>
Cc: Paul Moore <paul@...l-moore.com>,
 Maxime Bélair <maxime.belair@...onical.com>,
 Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
 linux-security-module@...r.kernel.org, jmorris@...ei.org, serge@...lyn.com,
 kees@...nel.org, stephen.smalley.work@...il.com, takedakn@...data.co.jp,
 linux-api@...r.kernel.org, apparmor@...ts.ubuntu.com,
 linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook

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@...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.
>>
>> 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