Re: RFE: use patchwork to submit a patch

[Mauro Carvalho Chehab <mchehab@kernel.org>]

Em Mon, 14 Oct 2019 09:53:58 -0400
"Theodore Y. Ts'o" <tytso@mit.edu> escreveu:

> On Mon, Oct 14, 2019 at 10:41:32AM -0300, Mauro Carvalho Chehab wrote:
> > It can still have man-in-the-middle (MITM) attacks between the sender and
> > vger.kernel.org. Please notice that using https and adding the patch
> > via a web interface can also be subject to MITM, as companies and even some
> > Countries with strong policy enforcement may have some gateway on their
> > infra that will prevent end-to-end encryption[1], blocking direct
> > client-server https tunnels.
> > 
> > [1] They add an internal certificate to the browsers, so that the client
> > will see the connection as trustful, but the infra will actually do two
> > separate HTTPS encryption:
> > 
> > 	client  ---> Gateway
> > 	Gateway ---> Server
> > 
> > While unlikely, nothing prevents that the patch would be maliciously 
> > altered at the Gateway.
> > 
> > From security PoV, the only way to ensure that the patch was not
> > altered is to have it signed by the one who wrote it.  
> 
> Well, sure, but the maintainer should be reviewing the patch looking
> for problems anyway.  There is the risk that people might slap a
> "Reviewed-by:" tag on a patch without sufficiently careful review if
> it's from a prominent kernel contributor, but we've always had that
> problem.  And so nothing, not even a digitally signed patch from a
> reviewer should absolve the maintainer from doing their own review.

Yeah, our current security model is based at the maintainer for
him to do his duties, properly reviewing the patch.

Yet, at the example that Daniel gave:

Instead of:

	if ((permissions == allowed) && other_stuff) {
		do_things();
	}
	do_more_stuff(permissions);

Patch was maliciously modified to:

	if ((permission == allowed) && other_stuff) {
		do_things();
	}
	do_more_stuff(permissions);

I suspect that a change like that might sleep though the maintainer's
review.

> 
> Now, one might argue that if there is a forged patch from "famous
> kernel developer A", followed up with a forged patch from "famous
> kernel developer B", that might cause a maintainer to happily take the
> patch without doing their own, independent review, for scaling
> reasons.  But that's a "vulernability" we've lived with for a long
> time, since today neither patches or "Reviewed-by" messages are
> usually signed.
> 
> And at least (as far as we know) no one has managed to sneak a
> malicious patch with a zero-day hidden with malice aforethought.  And
> perhaps that shouldn't be surprising.  We seem to be quite capable of
> introducing our own security vulererabilities without "help", so
> perhaps most malicious attackers wouldn't want to do something which
> could be so easily detected, when they can just pay money to a black
> hat hacker.

True, but, once we discover a patch introduced with a malicious code,
some action should be taken to eliminate the source of the bad code.

I mean, one thing is if "famous kernel developer A" maliciously
wrote a patch to violate security. The other thing is that the
infra used by "famous kernel developer A" is not safe, and has
some hidden back hat hacker in the middle of it.

The only way to identify that is by using signed patches/PRs.


Thanks,
Mauro