Message-ID: <1c686d2b-6b24-46b9-a439-5b696108d88e@canonical.com>
Date: Fri, 4 Oct 2024 21:24:06 -0700
From: John Johansen <john.johansen@...onical.com>
To: "Dr. Greg" <greg@...ellic.com>
Cc: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
 Paul Moore <paul@...l-moore.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Jonathan Corbet <corbet@....net>, 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:39, Dr. Greg wrote:
> On Wed, Oct 02, 2024 at 10:35:27PM -0700, John Johansen wrote:
> 
> Good morning, I hope the day is going well for everyone.
> 
>> On 10/2/24 21:26, Tetsuo Handa wrote:
>>> On 2024/10/03 11:45, John Johansen wrote:
>>>>> But due to above-mentioned realities, your assertion no longer stands.
>>>>> Kernel source itself might be open, but private keys cannot be open.
>>>>> The vmlinux cannot be rebuilt without forcing penalties (i.e. having a
>>>>> negative impact on the user side, which cannot be a viable solution).
>>>>>
>>>>>
>>>> Yes, and this is an intentional choice on the base of the distro about
>>>> what they support and what is required to meet contractual obligations.
>>>
>>> The reason Fedora cannot enable TOMOYO is lack of bandwidth.
> 
>> which is sadly a very valid argument. Coming from the distro side of
>> things it is a very real problem. I tend to advocate for giving the
>> user choice where we can but there is more than one occasion where
>> Ubuntu has had to declare bug bankruptcy on outstanding kernel bugs
>> because the backlog was impossible to handle.
> 
> Understand the concept of lack of bandwidth.
> 
> Had a 40 hour week in as of 0800 yesterday morning and the end of the
> week isn't even remotely in sight.

yeah I know that one all too well, I hit 40 hours some time Wednesday
morning.

> 
>>> You've just said "Bandwidth is a very real issue". Thus, I need a solution
>>> that can solve the bandwidth problem. The question is how we can control
>>> division of role (share the workload) in a secure manner.
> 
>> I do understand that. The problem is that out of tree doesn't do that.
>>  From a distro perspective out of tree is more work, and is very problematic
>> from a code signing perspective.
>>
>> Code signing isn't going away, if anything its become a requirement to
>> support the majority of users. Loading unsigned modules, code, even
>> bpf is a problem.
>>
>> Sure individual users can disable secure boot etc but at the distro
>> level we need to support secure boot out of the box. Out of tree code
>> really just isn't compatible with this.
> 
> Not relevant right now but I do remember, personally at a conference,
> Stallman railing on about the threat of signed code and what it
> represents with respect to software and device freedom.
> 
> And here we are....
> 
>>>> Users are still free to build their own kernels they just don't get
>>>> support or certification when using them.
>>>
>>> Nobody can provide bandwidth (or infrastructure) for supporting their
>>> locally built kernels.
> 
>> right
> 
>>>>                                            Stopping the load of out of
>>>> tree modules that aren't signed is in general good security policy.
>>>
>>> Yes, distributors can prevent load of out-of-tree modules that aren't
>>> signed. That is good for security. But building kernels locally cannot
>>> utilize signed modules functionality. Also,
> 
>> true. that is a limitation of the cryptography that is being used, and
>> I don't see a way to fix that
> 
>>>> Let me be explicitly clear. If Tomoyo is by-passing module signing, and
>>>> exporting the LSM interface to loadable modules Ubuntu will be forced
>>>> to disable Tomoyo.
>>>
>>> TOMOYO is one of in-tree modules that can be signed together when building
>>> distribution kernels. Fedora can provide tomoyo.ko as a
>>> signed-but-unsupported
>>> module (i.e. excluded from main kernel package that is supported by
>>> distributors but provided as a separate package that is not supported by
>>> distributors).
> 
>> yes it can, it has chosen not to. As I have said before that is a
>> choice/political reason, not technical. I wish I had a solution to
>> this problem for you but I don't. What I can say is Tomoyo adding
>> the ability to load out of tree code that isn't signed is going to
>> force Ubuntu to do the same and disable it. I really don't want to
>> do that, I would rather leave the choice available to our users.
>>
>> It may be a trade-off worth making for you/Tomoyo if it fixed your
>> problem with RHEL/Fedora but I don't see it fixing that problem
>> either.
> 
> Not much bandwidth for the rest of the day but I wanted to get this
> question/issue out to get some feedback for later tonight,
> particularly from your perspective John.
> 
> We saw these issues coming about four years ago, which is why we
> decided to take a deep breath and bring TSEM out of private use to a
> wider audience, it isn't a 'pet project' as it has been referred to.
> Not sure we would do that again but that is an issue for another day.
> 
> TSEM is based on the notion of having a generic modeling architecture
> for the LSM.  I know that Casey bristles at the notion of us saying
> 'model', but we can prosecute that argument in intimate detail at
> another time.
> 
> We would best characterize TSEM as a 'swiss army knife' for
> interpreting kernel security events.  You can run the event
> interpretation in the kernel, in userspace, in a hardware device or up
> in the cloud.
> 
> After watching Tetsuo's concerns over the last year we dropped the
> loadable module support into TSEM for the V4 release:
> 
> https://lore.kernel.org/linux-security-module/20240826103728.3378-1-greg@enjellic.com/T/#t
> 
> This offers the ability to run the interpretation model via code
> implemented in a loadable module.  BPF is also an option but we are
> keeping things simple at this point.
> 
> So we use the standard loadable module architecture.  We offer the
> ability to lock further model loads or unloads after a set of models
> have been loaded and the option to completely disable any loadable
> models at boot, independent of the general kernel loadable module
> state.
> 
> It doesn't fully fix Tetsuo's problem, given that a distribution could
> compile out TSEM, just like it compiles out Tomoyo, I think we all
> agree there is no fix to that problem.  However, if the security bigs
> like CrowdStrike, PaloAlto and others, understand that it allows EDR
> telemetry and surveillance to be implemented on Linux without having
> to install a high privilege or kernel based agent, it makes not having
> it in the kernel less attractive.
> 
> Just for the sake of advancing these conversations, we are throwing
> some bandwidth into implementing Tomoyo as a TSEM loadable module to
> get some further insight on the tractability of something like this.
> 
> With your distributor hat on does an architecture like this offend
> your security sensibilities?
> 
> Like it or agree with it, we seem to be standing at a reasonably
> important inflection point for Linux, conversations probably suitable
> for a 'Summit' type event.
> 
> Will look forward to your thoughts.
> 
honestly it worries me, but that is more a vague general worry about
any generic architecture that you can build on top of. Take BPF, it
has a whole host of issues, that make it very challenging, like
spectre gadgets, and getting its verifier correct for everything.
There is a lot of complexity there making it a challenge to evaluate.

I really need to dig into the details of TSEM before I can give a better
response.




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

Powered by blists - more mailing lists