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] [day] [month] [year] [list]

Message-ID: <71c3c2d6-5569-4580-89a4-513a03a429ab@schaufler-ca.com>
Date: Fri, 9 May 2025 07:21:29 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: John Johansen <john.johansen@...onical.com>,
 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>,
 Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook

On 5/9/2025 3:26 AM, 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
> 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.
>
> 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.

The development and maintenance of system calls is expensive in both
time and effort. LSM specific system calls frighten me. When I was
young adding system calls was just  not  done. A system call would
never be allowed for a specific sub-system or optional feature. True,
there are issues with the LSM specific filesystem approach. But I
like it, as it allows the LSM more freedom in its interfaces and
won't clutter the API if the LSM goes away or quits using it.