Looking for help testing patch attestation

Konstantin Ryabitsev konstantin at linuxfoundation.org
Wed Mar 18 15:11:36 UTC 2020


On Tue, Mar 17, 2020 at 06:51:38PM -0400, Paul Moore wrote:
> You might want to extend this test to the LSM list as well.  I'm
> refraining from CC'ing them on this email because I don't want to
> spoil your beta test rollout, but I think it would be a good thing to
> do.

I'll do that, thanks! I'll also loop in kernel-hardening folks.

> Speaking as the person who merges patches for both the SELinux and
> audit kernel subsystems, I look at every patch I merge; I don't
> blindly merge patches (even from certain "trusted" individuals).
> Simply put, I've always considered that to be part of the job.  While
> the patch attestation could provide some assurance about who created
> the patch (assuming a reasonable web-of-trust), and that it hadn't
> been tampered with, I feel it is more important to review correctness
> than it is to guarantee provenance.  If you ever develop a tool which
> can help with the correctness part, I'll gladly jump to the front of
> the line to test that one! ;)

Yes I understand -- I view this as an auxiliary feature that helps 
maintainers in their duties, but certainly doesn't aim to replace due 
diligence. I am most worried about the following scenario:

1. a maintainer receives a long series of patches that arrives into 
   their inbox
2. they carefully review the patches and decide to merge them
3. they use "b4 am" to grab that patch series from lore.kernel.org
4. however, the archive has been manipulated and returns patches 
   containing malicious edits, which get merged because the maintainer 
   assumes that what "b4 am" returns is the same as what they reviewed

Cryptographic attestations helps hedge against this scenario by removing 
any implicit trust from the centralized system like lore.kernel.org (or 
patchwork.kernel.org, for that matter).

> Having said that, I'm happy to see work going into tools like this,
> and at some point I'll look into adding it into my workflow for an
> extra level of safety (although I'm on the fence about making it
> mandatory for submissions).  Sorry to disappoint, but I'm probably not
> the best test monkey right now.

All good, this is why I'm casting the net wide looking for initial 
adopters. :)

Best regards,
Konstantin





More information about the Linux-audit mailing list