Re: BK2CVS problem
From: Theodore Ts'o (tytso_at_mit.edu)
Date: 11/06/03
- Previous message: Nick Piggin: "Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt"
- In reply to: bert hubert: "Re: BK2CVS problem"
- Next in thread: Rik van Riel: "Re: BK2CVS problem"
- Reply: Rik van Riel: "Re: BK2CVS problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 6 Nov 2003 08:22:13 -0500 To: bert hubert <ahu@ds9a.nl>, Scott Robert Ladd <coyote@coyotegulch.com>, Larry McVoy <lm@bitmover.com>, linux-kernel@vger.kernel.org
On Thu, Nov 06, 2003 at 11:06:07AM +0100, bert hubert wrote:
> On Wed, Nov 05, 2003 at 11:09:24PM -0500, Scott Robert Ladd wrote:
>
> > In other words, the theoretical exploit was inserted by someone clever.
> > Do we have any idea who?
>
> And, was there any route via which this malicious patch could've worked
> itself into a kernel release?
Not an official one, but maybe if some distribution was using the
secondary CVS repository instead of the primary BK repository.
(For people who think this is somehow a BK vs. CVS unfairness, it's
probably true --- remote's CVS's security properties are only best
described as terrifying. "CVS is not the answer. CVS is the
question. 'NO' is the answer...." :-)
To be fair, though, BK really needs to add per-changeset digital
signatures, and I've been bugging Larry about this for years. :-) And
there's a similar risk involving a subtle patch that claims to fix a
bug, but really opens up a security hole. Someone clever enough to
send a "patch" to Linus, who can forge sufficient mail headers that he
doesn't notice --- and perhaps even forge a cc to the LKML, even
though it never got sent there, might be able to sneak such a minor
change into the master sources. This is especially true if the trojan
horse gets burried in a number of other plausible changes, and had an
SMTP from field that appeared to come from a trusted kernel developer.
An argument might be made that all patches sent to Linus should be at
a minimum be GPG signed, but that assumes that Linus would be willing
to use GPG, or is willing to have his mail reader set upt to do
automatic GPG verification. One of the reasons why I think
integration with BK would be a Good Thing is that (a) it becomes
automatic, and (b) instead of it being verified only by Linus when he
receives the patch, I or anyone else can verify the digital signature
on each changeset whenever we want. This distributed verfication is
very powerful, and hopefully this points out why we badly need such a
capability.
- Ted
P.S. And once we have GPG signatures in BK, Larry could access
control lists that would only allow certain trusted key holders from
submitting changesets which modify the BK triggers script directory.
Why this is important is left as an exercise to the reader.... (And
before someone asks, CVS has the exact same vulnerability; in fact,
it's arguable that it's even worse in CVS.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Nick Piggin: "Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt"
- In reply to: bert hubert: "Re: BK2CVS problem"
- Next in thread: Rik van Riel: "Re: BK2CVS problem"
- Reply: Rik van Riel: "Re: BK2CVS problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
