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

[John Johansen]

On 10/2/24 23:16, Tetsuo Handa wrote:
> On 2024/10/03 14:35, John Johansen wrote:
> > 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.
>
> Confused. If use of BPF is a problem, use of BPF-LSM is also a problem?

yes it is. Pressures being what they are, it is enabled for some of our
kernels. Signed BPF would be required to get it available every where.

> If one were able to implement security modules using BPF-LSM, such modules
> are headache for distributors? If so, BPF based LSM modules can't be a
> candidate for replacing C based LSM modules...

I have never argued they were. But they are currently the only solution for
out of tree LSM modules if you don't want to rebuild the kernel.

> > 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.
>
> More we want to enforce protecting with module signing, more we need to make
> whatever code built-in and run in the kernel space. Upstream-first pressure
> will push whatever code for inclusion into the upstream kernel.
>
>
>
> > > 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 does "it" referring to? Fedora has chosen not to build TOMOYO into Fedora's
> vmlinux. But I haven't heard from Fedora that Fedora won't ship tomoyo.ko as a
> separate package.
yeah fedora/RHEL, they don't build apparmor either. And I do not believe that
building tomoyo.ko will get them to ship it in a separate package. That separate
package is more work than a builtin tomoyo and the kernel memory savings are
minimal.

With KP's performance patch the performance overhead of a builtin tomoyo is
negligible.

> >                               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.
>
> How is tomoyo.ko connected to loading of out-of-tree code? If the module signing
> can prevent unsigned modules from loading, where is the possibility of loading
> unsigned LSM modules even if LSM hooks are exported to loadable modules?

sorry was tired and in rush, and dumping in the other worries I have here. Exporting
symbols itself has nothing to do with module signing. However as Kees pointed
out in another email it does become an attack target.

The other one is I don't believe tomoyo,ko is going to get built as part of
the fedora/RH infrastructure. Which means module signing will block it. You went
for a "technical" solution on the symbols export, by-passing the community.
What is the next technical solution to get around module signing. Over the top,
paranoid, maybe. Do I think its highly unlikely, yes, but it became a worry as
soon as you pushed this patchset.

>   From module signing perspective, there will be no difference between the LSM
> framework exports LSM hooks and TOMOYO exports LSM hooks. And
> https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@xxxxxxxxxxxxxxxxxxx
> leaves the choice available to distro users. Why not acceptable?
>
> By some chance..., can't module signing prevent any code (both in-tree and
> out-of-tree) that is not signed from loading !?
as long as it goes through the module infrastructure sure.