After UMN Debacle, Patatt Aims To Provide Cryptographic Attestation For Patches

[phoronix]

Phoronix: After UMN Debacle, Patatt Aims To Provide Cryptographic Attestation For Patches

Linux kernel developer Konstantin Ryabitsev has been working on Patatt as a cryptographic-based patch attestation system. While started a while ago, there is renewed interest in such patch attestation following the University of Minnesota "hypocrite commit" debacle...

https://www.phoronix.com/scan.php?page=news_item&px=Patatt-Attestation

[baka0815]

What's the point in using this? Aren't patches already reviewed and 'reviewed-by'?
Why do you need to sign your 'reviewed-by'?
If those patches landed in the kernel without reviews, the process is broken.
If the patches landed in the kernel with reviews, it was human error.
In neither way is the patatt-tool helping.

[skeevy420]

What's the point in using this? Aren't patches already reviewed and 'reviewed-by'?
Why do you need to sign your 'reviewed-by'?
If those patches landed in the kernel without reviews, the process is broken.
If the patches landed in the kernel with reviews, it was human error.
In neither way is the patatt-tool helping.

I suppose this helps if someone spoofs a kernel dev's email address. Even in that scenario GKH or Linus or Reviewed-By would have to drop the ball and not catch the malicious act in the review as well as the kernel dev being spoofed would have to not notice all the emails they've sent or the replies they might be getting.

I also feel like this is a problem that Git has solved.

[r_a_trip]

It will add a layer for authenticating the sender, but it won't do any good in weeding out malicious patches. The UMN submitters were known. Their patches were deliberately flawed. The patches didn't reach mainline. So the process works in that regard, but extra authentication doesn't stop a bad actor from trying to poison the project.

[oiaohm]

I suppose this helps if someone spoofs a kernel dev's email address. Even in that scenario GKH or Linus or Reviewed-By would have to drop the ball and not catch the malicious act in the review as well as the kernel dev being spoofed would have to not notice all the emails they've sent or the replies they might be getting.

I think you missed a feature same did the write up.

https://people.kernel.org/monsieuricon/end-to-end-patch-attestation-with-patatt-and-b4

git commits themselves can be cryptographically signed, which allows a small subset of developers to act as “trusted introducers” to many other contributors (mimicking the “keysigning” process)

This is in fact a full end to end process. So this designed that if a patch is signed using this process it remains signed after its commit-ed to git.

Remember you may be using a Linux kernel fork for some reason on someones own git. This does provide means to validate that they have not been playing silly buggers and adding patches under other people names as well. So there are paths that patches can be added to Linux kernel branches that will not pass GKH or Linux reviewed email boxes that parties could decide to lie that the patches have been reviewed.

It will add a layer for authenticating the sender, but it won't do any good in weeding out malicious patches. The UMN submitters were known. Their patches were deliberately flawed. The patches didn't reach mainline. So the process works in that regard, but extra authentication doesn't stop a bad actor from trying to poison the project.

There is more than the UMN way to be bad actor. This goes after a different form where someone forks the git tree itself and decides to play silly buggers with it.

How it relates to a UMN way makes it harder for a person to say it was not them that someone spoofed their email as excuse for a bad patch. Think a threat vector where a person submits a stack of good patches to look good then submits a set of true 100 percent sure evil patches and they claim my email account got broken into and spoofed. Is this what happened now if it end to end signed with the same normal key they use you would say no email spoofing either their system is breached or they are being forced by someone to submit a bad commit.

There is history where the kernel.org website itself has been hacked. So the possibility that the git tree gets modified after GKH or Linus is done with it is a real possibility as well.

There are quite a few threat vectors to software development. Git is resistant to quite a few attack vectors by design but it still has git weaknesses. This does offer way to close some of the remaining weaknesses.

[Luke_Wolf]

[Snip]
There is more than the UMN way to be bad actor. This goes after a different form where someone forks the git tree itself and decides to play silly buggers with it.

Which would effect... who? All of the distros are all running their own forked version of the Linux kernel with their patches layered on top and if their infrastructure is at all sane they're set up to be pulling from and rebasing on the upstream git repo rather than the release tars,

[hotaru]

The UMN submitters were known. Their patches were deliberately flawed. The patches didn't reach mainline. So the process works in that regard, but extra authentication doesn't stop a bad actor from trying to poison the project.

if the patches didn't reach mainline, why did they need to be reverted?

[stormcrow]

I think you missed a feature same did the write up.

https://people.kernel.org/monsieuricon/end-to-end-patch-attestation-with-patatt-and-b4

Lots of verbiage...

Except none of this would stop a malicious patch from a believed reputable source. Which was the point of UMN's "research" and was already the known skeleton in free collaborative development. This system is not too different from blockchain adherents pushing immutable ledgers. It doesn't, and can't, solve the "poisoning the well" scenario in the first instance. The only way it can be solved is by a rigorous code review process. I can see the system potentially replacing multi-stop GPG verifications, but nothing is going to stop the threat agent that generates trust with helpful patches, then deliberately trojan horses a subsequent patch later on except skilled code security auditors. That's what some people are claiming this system addresses, but it very obviously doesn't and can't. This is a social engineering exploit. Compromises to the system before it reaches the cryptographic chain can't be stopped by a cryptographic chain, it can't even be verified by the chain to have occurred or not occurred.

[oiaohm]

Which would effect... who? All of the distros are all running their own forked version of the Linux kernel with their patches layered on top and if their infrastructure is at all sane they're set up to be pulling from and rebasing on the upstream git repo rather than the release tars,

Rebasing on the upstream git repo does not always happen. Like you have android devices rebasing on the android fork of the Linux kernel instead of upstream at times. Then you have countries with the likes the china with the great firewall that could be in the middle making kernel.org not be what you think it is.

if the patches didn't reach mainline, why did they need to be reverted?

Because this is a triggered poisoned well event. Yes those doing the research did not get their patches in the fact they tried they triggered that the University was a possible poisoned well causing all patches from that source to be pulled and reinspected.

Except none of this would stop a malicious patch from a believed reputable source. Which was the point of UMN's "research" and was already the known skeleton in free collaborative development. This system is not too different from blockchain adherents pushing immutable ledgers. It doesn't, and can't, solve the "poisoning the well" scenario in the first instance. The only way it can be solved is by a rigorous code review process. I can see the system potentially replacing multi-stop GPG verifications, but nothing is going to stop the threat agent that generates trust with helpful patches, then deliberately trojan horses a subsequent patch later on except skilled code security auditors.

First bit how to detect if a reputable source is still so is what this is to help with. Lets deal with that threat agent example you just used. Lets say the person has been submitting patches for years before they do something really bad and now they claim their email account was hacked so the defective patches that threat agent sent were not theirs. See where it fits in now signed patches/commit reduces your means to disown your work good or bad.

Rigorous code review only gets you so far as that only tells you the patch is bad not proof the person or person system is bad who name is on the patch/commit. Yes signed patches/commits is not perfect but it does limit the problem to the person or the person system instead of possible any source on the internet that could have faked the emails/commits.

"Malicious patch from a believed reputable source" that is always going to be a problem. There are two things the signed patches/commits is to-do
1) Make it harder to fake being a reputable source.
2) Threat agent does patches to gain trust then from there appears a patch that is bad limit their means to talk their way out of it. So limit the number of attempts they get per developed trust.

Reality here stormcrow no matter how skilled code security auditors are they are not perfect. When someone is caught doing the wrong thing you don't want them to be able to simply talk their way out of it claiming the patch/commit was not theirs when it was theirs. Yes this links to the same thing the UMN's research was doing just its a different side of the problem. Signed patches/commits is more the hand cuffs/prison side of making sure caught person doing the wrong thing is going to have a lot harder time talking their way out. Code security auditors reality is less than half of the solution you need to be able to confirm who was behind a exploit patch to make sure you kill the correct person reputation.