Message-ID: <83a32e86-cdc2-4068-b830-b54aaea1e01a@canonical.com>
Date: Fri, 4 Oct 2024 21:37:28 -0700
From: John Johansen <john.johansen@...onical.com>
To: "Dr. Greg" <greg@...ellic.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 Paul Moore <paul@...l-moore.com>, Jonathan Corbet <corbet@....net>,
 Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
 LKML <linux-kernel@...r.kernel.org>, linux-security-module@...r.kernel.org
Subject: Re: [GIT PULL] tomoyo update for v6.12

On 10/3/24 08:43, Dr. Greg wrote:
> On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:
> 
>> On 10/2/24 03:38, Dr. Greg wrote:
>>> On Tue, Oct 01, 2024 at 09:36:16AM -0700, Linus Torvalds wrote:
>>>
>>> Good morning Linus, I hope the week is going well for you.
>>>
>>> Some reflections, for the record, on this issue.
>>>
>>>> On Tue, 1 Oct 2024 at 07:00, Paul Moore <paul@...l-moore.com> wrote:
>>>>>
>>>>> Linus, it's unclear if you're still following this thread after the
>>>>> pull, but can you provide a little insight on your thoughts here?
>>>
>>>> I absolutely hate the whole "security people keep arguing", and I
>>>> cannot personally find it in myself to care about tomoyo.  I don't
>>>> even know where it is used - certainly not in Fedora, which is the
>>>> only distro I can check quickly.
>>>>
>>>> If the consensus is that we should revert, I'll happily revert. This
>>>> was all inside of the tomoyo subdirectory, so I didn't see it as
>>>> some kind of sidestepping, and treated the pull request as a regular
>>>> "another odd security subsystem update".
>>>
>>> I see that Paul Moore has further responded with commentary about the
>>> 'LSM community' responding to this issue.  I wanted, on behalf of our
>>> project and in support of Tetsuo's concerns, to register directly with
>>> you a sense of jaded skepticism about the notion of a community
>>> response.
>>>
>>> Fixing Tetsuo's issue, at least to the extent it can be fixed,
>>> requires technical improvements in the Linux security architecture.
> 
>> yes and that is correct place to do it. Doing it within a single
>> LSM is very much the wrong approach
> 
> Just going out the door and saw this e-mail
> 
> Your e-mail crossed with one I just sent over in the kernel code
> loading side of this thread/debate.
> 
> Will look forward to seeing your thoughts there.
> 
This one is a hard problem. I don't have a good solution. We are
pushing up against lots of constraints: performance (see KP's patch),
the need to get rid of/reduce use of indirect branches because of
spectre (again performance but also brittleness), the desire to
make the LSM less of a target for kernel compromises (ro after init).
The need for code signing and integrity. The need for common interfaces
(LSM syscalls), to avoid the interface sins of the past.

This makes loadable LSMs troublesome at best and I concede maybe
impossible politically.

I am not entirely opposed to the approach that Tetsuo took. Its
interesting, and I wouldn't have minded it being explored more as a way
to extend the LSM, but as part of the LSM, not in crammed into an
individual LSM.

The performance hit for its use I am willing to accept because,
it only happens if it is enabled. So it would be easy to build it
in and just not enable it by default.

It would still have to show how to deal with ro of the hooks, make
sure we aren't introducing new spectre gadgets, and also have a
way to integrate with LSM syscalls, and probably a few other
things I am missing.

These are all things that would need to be discussed on list.


> As always,
> Dr. Greg
> 
> The Quixote Project - Flailing at the Travails of Cybersecurity
>                https://github.com/Quixote-Project

Powered by blists - more mailing lists