Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <dd27f643-38e8-b312-72ce-77d1dc962a68@schaufler-ca.com>
Date:   Mon, 28 Nov 2022 11:07:03 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: [PATCH v3 1/9] LSM: Identify modules by more than name
Content-Language: en-US
To:     Paul Moore <paul@paul-moore.com>,
        Greg KH <gregkh@linuxfoundation.org>
Cc:     =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= <mic@digikod.net>,
        casey.schaufler@intel.com, linux-security-module@vger.kernel.org,
        jmorris@namei.org, keescook@chromium.org,
        john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp,
        stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org,
        linux-api@vger.kernel.org, casey@schaufler-ca.com
References: <20221123201552.7865-1-casey@schaufler-ca.com>
 <20221123201552.7865-2-casey@schaufler-ca.com> <Y38D1s3uQ6zNORei@kroah.com>
 <463cb747-5bac-9e8e-b78e-1ff6a1b29142@digikod.net>
 <CAHC9VhR9h1GF6VGovp1+UB-vt+QNofjmecPwLqE3OviKQHRMcg@mail.gmail.com>
 <Y4Rok2iAOekw/tSJ@kroah.com>
 <184be48c558.28e3.85c95baa4474aabc7814e68940a78392@paul-moore.com>
From:   Casey Schaufler <casey@schaufler-ca.com>
In-Reply-To: <184be48c558.28e3.85c95baa4474aabc7814e68940a78392@paul-moore.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 11/28/2022 4:49 AM, Paul Moore wrote:
> On November 28, 2022 2:51:55 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
>> On Sun, Nov 27, 2022 at 10:48:53PM -0500, Paul Moore wrote:
>>> On Fri, Nov 25, 2022 at 11:19 AM Mickaël Salaün <mic@digikod.net> wrote:
>>>> 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?

The interface is designed to extend to attributes beyond those which
are active today. Currently all the attributes are specific to the
individual modules. The LSM infrastructure itself has no variable state,
but that may change. One proposal would allow loadable modules, in which
case an attribute such as LSM_IS_LOADABLE might identify the dynamic
modules. Another potential attribute could be which security module is
responsible for network labeling via netlabel. That could be LSM_NETLABEL.
Another possible attribute could be related to stacking behavior in a
namespaced environment.

While it would be possible to intermingle the LSM infrastructure attribute
values with the security module provided values, separating them makes for
a clearer distinction.

>>>> 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.
>>> I haven't finished reviewing this latest patchset, but I wanted to
>>> comment on this quickly while I had a moment in front of a keyboard
>>> ... I did explain my desire and reasoning for this in a previous
>>> revision of this patchset and I still believe the
>>> reserved-for-potential-future-use to be a valid reason so I'm going to
>>> ask for this to remain.
>> Then that reasoning and explaination needs to be here in the changelog
>> so that we understand and have a chance to agree/disagree with that.
>> Otherwise we, and everyone else, are left to just be confused.
>>
>> thanks,
>>
>> greg k-h
> The patch author should have done that considering I made my comments on the last revision.
>
> --
> paul-moore.com
>
>