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: <47483d3d-380a-36e9-0c7f-9becfc09a656@schaufler-ca.com>
Date:   Mon, 7 Nov 2022 09:21:35 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default
 LSM stack ordering
Content-Language: en-US
To:     =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= <mic@digikod.net>,
        Paul Moore <paul@paul-moore.com>,
        Kees Cook <keescook@chromium.org>
Cc:     Nicolas Iooss <nicolas.iooss@m4x.org>,
        James Morris <jmorris@namei.org>,
        "Serge E . Hallyn" <serge@hallyn.com>,
        linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= <mic@linux.microsoft.com>,
        casey@schaufler-ca.com
References: <20210222150608.808146-1-mic@digikod.net>
 <20210222150608.808146-2-mic@digikod.net>
 <51725b44-bc40-0205-8583-285d3b35b5ca@schaufler-ca.com>
 <ee461f8d-a02d-0782-8f31-691853a57f00@digikod.net>
 <7b67163a-9de1-313f-5b5a-8c720cef9b73@schaufler-ca.com>
 <CAJfZ7=n5FOxHXMLRrDQ3F-kDqbYngNoYKcz6_PWi1rPa0_8WpA@mail.gmail.com>
 <3b97e25b-303c-d732-3e5d-f1b1a446e090@schaufler-ca.com>
 <202210171111.21E3983165@keescook>
 <CAHC9VhTTKpesvjnc_233x+wG1BvXyup9nM4Dv2h1953zXAvU3A@mail.gmail.com>
 <202210172153.C65BF23D5E@keescook>
 <CAHC9VhSMLjzxyu0F82NZoea-q4yMgHeCZ0-TRcvxKks4WeKacQ@mail.gmail.com>
 <c7808c82-621e-c20d-bff3-03a66df5528a@digikod.net>
 <b0e100f9-146c-2709-3946-67bc06282b91@schaufler-ca.com>
 <955d9b89-3ca1-8c70-0c05-759febde4031@digikod.net>
From:   Casey Schaufler <casey@schaufler-ca.com>
In-Reply-To: <955d9b89-3ca1-8c70-0c05-759febde4031@digikod.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 11/7/2022 4:35 AM, Mickaël Salaün wrote:
>
> On 04/11/2022 18:20, Casey Schaufler wrote:
>> On 11/4/2022 9:29 AM, Mickaël Salaün wrote:
>>>
>>> On 18/10/2022 21:31, Paul Moore wrote:
>>>> On Tue, Oct 18, 2022 at 1:55 AM Kees Cook <keescook@chromium.org>
>>>> wrote:
>>>>> On Mon, Oct 17, 2022 at 09:45:21PM -0400, Paul Moore wrote:
>>>
>>> [...]
>>>
>>>>>> We can have defaults, like we do know, but I'm in no hurry to remove
>>>>>> the ability to allow admins to change the ordering at boot time.
>>>>>
>>>>> My concern is with new LSMs vs the build system. A system builder
>>>>> will
>>>>> be prompted for a new CONFIG_SECURITY_SHINY, but won't be prompted
>>>>> about making changes to CONFIG_LSM to include it.
>>>>
>>>> I would argue that if an admin/builder doesn't understand what a shiny
>>>> new LSM does, they shouldn't be enabling that shiny new LSM.  Adding
>>>> new, potentially restrictive, controls to your kernel build without a
>>>> basic understanding of those controls is a recipe for disaster and I
>>>> try to avoid recommending disaster as a planned course of action :)
>>>
>>> It depends on what this shiny new LSMs do *by default*. In the case of
>>> Landlock, it do nothing unless a process does specific system calls
>>> (same as for most new kernel features: sysfs entries, syscall flags…).
>>> I guess this is the same for most LSMs.
>>
>> "By default" is somewhat ambiguous. Smack will always enforce its
>> basic policy. If files aren't labeled and the Smack process label
>> isn't explicitly set there won't be any problems. However, if files
>> have somehow gotten labels assigned and there are no rules defined
>> things can go sideways.
>
> Right, it should then mean without effect whatever kernel-mediated
> persistent data (e.g. FS's xattr), but I agree that the limit with an
> explicit configuration can be blurry. I guess we could explicitly mark
> LSMs with a property that specify if they consider safe (for the
> system) to be implicitly enabled without explicit run time configuration.

In the Smack example, the system would be "safe" from the standpoint
of system security policy. It might not "work", because the enforcement
could prevent expected access. There is no simple way to identify if an
LSM is going to need configuration, and can be counted on having it, at
initialization. It's up to the LSM to decide what to do if it isn't
properly initialized.