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: <463cb747-5bac-9e8e-b78e-1ff6a1b29142@digikod.net>
Date:   Fri, 25 Nov 2022 17:19:01 +0100
From:   Mickaël Salaün <mic@...ikod.net>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Casey Schaufler <casey@...aufler-ca.com>
Cc:     casey.schaufler@...el.com, paul@...l-moore.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
Subject: Re: [PATCH v3 1/9] LSM: Identify modules by more than name


On 24/11/2022 06:40, Greg KH wrote:
> On Wed, Nov 23, 2022 at 12:15:44PM -0800, 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().
>>
>> The values are for LSM identifiers are defined in a new UAPI
>> header file linux/lsm.h. Each existing LSM has been updated to
>> include it's LSMID in the lsm_id.
>>
>> The LSM ID values are sequential, with the oldest module
>> LSM_ID_CAPABILITY being the lowest value and the existing modules
>> numbered in the order they were included in the main line kernel.
>> This is an arbitrary convention for assigning the values, but
>> none better presents itself. The value 0 is defined as being invalid.
>> The values 1-99 are reserved for any special case uses which may
>> arise in the future.
> 
> What would be a "special case" that deserves a lower number?

I don't see any meaningful use case for these reserved numbers either. 
If there are some, let's put them now, otherwise we should start with 1. 
Is it inspired by an existing UAPI?
Reserving 0 as invalid is good though.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ