linux-kernel - Re: [PATCH v1 7/8] LSM: Create lsm_module

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]

Date:   Wed, 9 Nov 2022 17:37:14 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     casey.schaufler@...el.com, linux-security-module@...r.kernel.org,
        jmorris@...ei.org, keescook@...omium.org,
        john.johansen@...onical.com, penguin-kernel@...ove.sakura.ne.jp,
        stephen.smalley.work@...il.com, linux-kernel@...r.kernel.org,
        linux-api@...r.kernel.org, mic@...ikod.net, casey@...aufler-ca.com
Subject: Re: [PATCH v1 7/8] LSM: Create lsm_module_list system call

On 11/9/2022 3:35 PM, Paul Moore wrote:
> On Tue, Oct 25, 2022 at 2:48 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>> Create a system call to report the list of Linux Security Modules
>> that are active on the system. The list is provided as an array
>> of LSM ID numbers.
>>
>> The calling application can use this list determine what LSM
>> specific actions it might take. That might include chosing an
>> output format, determining required privilege or bypassing
>> security module specific behavior.
>>
>> Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
>> ---
>>  include/linux/syscalls.h |  1 +
>>  kernel/sys_ni.c          |  1 +
>>  security/lsm_syscalls.c  | 38 ++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 40 insertions(+)
> ..
>
>> diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
>> index da0fab7065e2..cd5db370b974 100644
>> --- a/security/lsm_syscalls.c
>> +++ b/security/lsm_syscalls.c
>> @@ -154,3 +154,41 @@ SYSCALL_DEFINE3(lsm_self_attr,
>>         kfree(final);
>>         return rc;
>>  }
>> +
>> +/**
>> + * lsm_module_list - Return a list of the active security modules
>> + * @ids: the LSM module ids
>> + * @size: size of @ids, updated on return
>> + * @flags: reserved for future use, must be zero
>> + *
>> + * Returns a list of the active LSM ids. On success this function
>> + * returns the number of @ids array elements. This value may be zero
>> + * if there are no LSMs active. If @size is insufficient to contain
>> + * the return data -E2BIG is returned and @size is set to the minimum
>> + * required size. In all other cases a negative value indicating the
>> + * error is returned.
>> + */
> Let's make a promise that for this syscall we will order the LSM IDs
> in the array in the same order as which they are configured/executed.

Sure. Order registered, which can vary, as opposed to LSM ID order,
which cannot. That could be important to ensure that applications
that enforce the same policy as the kernel will hit the checks in
the same order as the kernel. That's how it is coded. It needs to
be documented. 

> I'm doubtful that only a *very* small number of applications will care
> about this (if any), but this is something we can do so let's do it
> now while we can.
>
>> +SYSCALL_DEFINE3(lsm_module_list,
>> +               unsigned int __user *, ids,
>> +               size_t __user *, size,
>> +               unsigned int, flags)
> --
> paul-moore.com