Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

On Fri, 2006-05-19 at 15:13 +0100, Chris Bainbridge wrote:
> There are now several hundred gentoo developers. It is more likely
> that one of them has a security lapse than cvs.gentoo.org.
One is a "local" bug, the other one "global".
I'd prefer a system that is resilient against two devs going crazy -
right now the "right" persons could stage a manipulation that would be
hard to detect and where your (single central) signature fails quite
nicely.

> It is a single signature across the entire portage tree. It means that
> after rsync emerge can check the signature against the retrieved tree
> to validate the whole tree (or overlay).
It's very coarse - Yes / No
Doesn't tell you what failed how ... so I DoS it by inserting one bit on
any rsync mirror and it will "fail". You don't know what fails where ...

> Instead of guessing performance, test it. We can assume that disk
> activity is negligible  - we have a dedicated server, and the portage
> tree is ~115MB, so most of it will be cached in main memory. In
> particular there is no disk seek latency. To simulate that we can
> gather everything into a single file (which also has the side effect
> of pulling into the cache) and then gpg sign that file:
>
> find /usr/portage -path '/usr/portage/metadata' -prune -o -path
> '/usr/portage/distfiles' -prune -o -path '/usr/portage/packages'
> -prune -o -type f -exec cat {} > /tmp/blah \;
> time gpg --detach-sign -a /tmp/blah
>
> I get 1.5 seconds on a desktop and 6.5 seconds on a laptop.
ok

> > > The benefits of this would be that changes are minimised - developers
> > > and users act the same, the impact on the tree is a 191 byte
> > > signature, and yet it will protect against the most likely and most
> > > practical form of attack.
> > So ... DoS scenario
> > I just add one byte to the tree and the signature fails ... what then?
>
> Emerge informs the user that the rsync server has been corrupted and
> terminates. How would this be any different with distributed file
> signing?
You can't upgrade and you don't know what fails where ...

>  You have to rsync the entire tree, and then verify it - at
> that point the tree is already corrupt. Ideally overlayfs (or just
> plain old keeping a backup) could be used to restore the pre-sync
> tree.
Right, but ... what caused the error?

> It could be done in stages. Start with the (easier) central key, then
> later add distributed keys. I think a hybrid system would be the ideal
> system, but realistically, bug #5902 has been around since March 2003
> and no real progress has been made.
That bug appears quite unrelated to me ... how does FEATURES="userpriv"
relate to signing?

>  The main sticking point seems to
> be disagreements over key management and policies. I would hope that
> most people could agree that a single key with a post-commit signing
> is better than what we have now,
debatable
> and could be easily implemented,
yes
> whilst leaving open the option of a hybrid system implementation at a
> later date.
yes

but that's not a cure. You'd have to sign _each file_ to get a
reasonable tampering detection, or at least per-directory. You add a
single point of failure and give attackers a high-profile target.

It's like security checks at the airport: It gives you the illusion of
security, it inconveniences everybody ... and it's easier for me to
smuggle a bomb aboard because noone thinks it's possible. (It's easy,
use a sidechannel attack on the baggage transports, they have bad
security ...)

Patrick
-- 
Stand still, and let the rest of the universe move