linux-kernel - Re: [PATCH v15 01/11] LSM: Identify modules by more than name

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: <30d1110a-7583-4fa1-85c8-d6ce362f5ae2@schaufler-ca.com>
Date:   Fri, 20 Oct 2023 12:52:49 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        paul@...l-moore.com, linux-security-module@...r.kernel.org
Cc:     jmorris@...ei.org, serge@...lyn.com, keescook@...omium.org,
        john.johansen@...onical.com, stephen.smalley.work@...il.com,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        mic@...ikod.net, Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v15 01/11] LSM: Identify modules by more than name

On 10/5/2023 5:58 AM, Tetsuo Handa wrote:
> On 2023/09/13 5:56, Casey Schaufler wrote:
>> Create a struct lsm_id to contain identifying information about Linux
>> Security Modules (LSMs). At inception this contains the name of the
>> module and an identifier associated with the security module.  Change
>> the security_add_hooks() interface to use this structure.  Change the
>> individual modules to maintain their own struct lsm_id and pass it to
>> security_add_hooks().
> I came to worry about what purpose does the LSM ID value (or more precisely,
> "struct lsm_id") is used for. If the LSM ID value is used for only switch
> {reading,writing} /proc/self/attr/ of specific LSM module's information, only
> LSM modules that use /proc/self/attr/ will need the LSM ID value.
>
> But this series uses "struct lsm_id" as one of arguments for security_add_hooks(),
> and might be reused for different purposes.
>
> Then, BPF-based LSMs (which are not considered as in-tree LSM modules, for
> only BPF hook is considered as in-tree LSM module) might receive unfavorable
> treatment than non BPF-based LSMs? 
>
> [PATCH v15 05/11] says
>
>   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 choosing an
>   output format, determining required privilege or bypassing
>   security module specific behavior.
>
> but, at least, name of BPF-based LSMs won't be shown up in lsm_list_modules()
> compared to non BPF-based LSMs? Then, the calling application can't use this
> list determine what BPF-based LSM specific actions it might take?

That is correct. Just as knowing that your system is using SELinux won't
tell you whether a specific action might be permitted because that's driven
by the loaded policy, so too knowing that your system is using BPF won't
tell you whether a specific action might be permitted because that's driven
by the eBPF programs in place.

I wish we could stop people from saying "BPF-based LSM". BPF is the LSM. The
eBPF programs that implement a "policy" are NOT a LSM. There needs to be a
name for that, but LSM  is  not  it.