Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-security
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-security@g.o
From: Brian Bilbrey <bilbrey@...>
Subject: Re: No, apparently not.
Date: Sun, 07 Nov 2004 21:17:04 -0500
Peter Simons wrote:
> So if you guys would like to be the laughing stock of the
> free software community once this vulnerability is exploited
> for the first time, all I say is: Be my guest.

How is this NOT a problem with every distribution that offers downloads
... oh, that's right ... ALL of them? Yep.

Instead of a bunch of hounds baying at the Gentoo devs, who do what they
 do without much in the way of remuneration, and who have absolutely the
best intentions and concern for the user base ... why not HELP them
design a tool that can help ameliorate the risk to some acceptable level.

I'll agree that having signed files will be a step forward in security,
but also ack that in the larger scheme of things, it means little. But
progress in a forward direction is always a good thing. Now, how about
an independent signature/hash of the entire portage tree?

If I wanted something like that, I might start with some assumptions
(any of which may be false, but I'm using the assumptions to generate a
scenario):

1. The master machine (or cluster or whatever) is the source of
distribution to a limited set of secondary mirrors, from which all other
mirrors sync, and from those, end users sync.

2. So an end user is perhaps two, but likely three steps away from the
master.

3. The secondaries sync to the master on a known schedule ... let's say
hourly.

4. Commits to the master currently happen on no set schedule.

Okay, with those four assumptions, could we do something like this:

1. Queue up commits to the master for 55 minutes of every hour.

2. At minute 55, close off access by the secondary mirrors.

3. Apply the commits to the master.

4. Write a datestamp/serial number into the master, then run a hash
against it. Put that hash on the gentoo main site, and other places
where the portage tree is not mirrored, either appended to the hashfile
(as a serial number / hash pair) or as a standalone hash in a file
that's named for the serial number, in a directory full of such things.

	For example:
	
	export FILENAME=`date | md5sum | cut -f1 -d' '`
	echo $FILENAME >> /usr/portage/serial_number
	tar cf - /usr/portage --exclude distfiles | md5sum \
		>> /root/$FILENAME

	[copy the /root/$FILENAME over to the appropriate distribution points,
webservers, whatever]

5. Reopen access by the secondaries.


Then, at the user end, after performing an emerge sync, the process is
run again, by portage:
	
	export FILENAME=`cat /usr/portage/serial_number`
	wget http://www.gentoo.org/$FILENAME
		# thus retrieving the checksum for that particular
		# snapshot
	tar cf - /usr/portage --exclude distfiles | md5sum | \
		diff - $FILENAME

If the checksums match, the diff returns 0, clean tree, and we can all
start worrying about the packages that are downloaded from the URLS
contained in each ebuild.

To break this, the main mirror can be compromised (one must presume that
this is protected) OR a secondary or tertiary mirror can be owned, along
with at least one source of the checksum file, which are independent of
all mirror machines. Of course, the combinations of mirror and checksum
sources mean that alarm bells will be going off pretty quickly, unless
the main mirror is owned. Then all bets are off, but eventually we all
die, right?

Okay, that's one scenario, based upon possibly silly assumptions. But it
or something like it could be implemented. I could probably even pretend
to be able to help with a portage patch, except that I have no concept
of the actual infrastructure for portage tree distribution, which will
tie into how portage works with such a scheme.

Let's be useful to the developers here, folks. Hell, I'm pissed off
about some of what I've read in this thread, and I don't have any axe to
grind in the matter.

HTH,

.brian

--
Brian Bilbrey : http://www.orbdesigns.com/
  ... maybe they can't be called "volunteers" any more if somebody
  ends up being silly enough to pay them for something they'd have
  done for free anyway. - Linus in the Seattle Times

--
gentoo-security@g.o mailing list

Replies:
Re: No, apparently not.
-- Ed Grimm
Re: No, apparently not.
-- Peter Simons
References:
Trojan for Gentoo, part 2
-- Alexander Holler
Is anybody else worried about this? (was: Trojan for Gentoo, part 2)
-- Peter Simons
Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)
-- Kurt Lieber
Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)
-- Chris Frey
Re: Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)
-- Kurt Lieber
No, apparently not. (was: Is anybody else worried about this?)
-- Peter Simons
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Keys on a cd?
Next by thread:
Re: No, apparently not.
Previous by date:
Gentoo's security
Next by date:
Re: No, apparently not.


Updated Jun 17, 2009

Summary: Archive of the gentoo-security mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.