Re: [GIT PULL] tomoyo update for v6.12

[John Johansen]

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@xxxxxxxxxxxx/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