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

[Peter]

On Thu, 18 May 2006 23:45:17 +0200, Patrick Lauer wrote:

>The problem, in short, is how to handle the checksumming and signing of
>gentoo-provided files so that manipulation by external entities becomes
>difficult.

all snip...

PMFJI, but as a user, not a security expert, I had a few thoughts that I'd
like to throw in. Thanks to Patrick, he helped me to drill down some of
the ideas and I present them for consideration. It's just a framework, so
I will be brief.

Here are the main requirements of this scheme:

1) I believe there should be a gentoo uber-key. One, similar to Slackware
Security, which is used to authenticate everything coming from Gentoo.

2) Every first or second level directory in portage should have a Manifest
of all files in it and below, not just ebuilds. All ebuilds have Manifest
files, but eclass does not, and profiles does not AFAIK. These Manifest
files, like now, will contain checksums of all files in and below its
directory.

(right now, signing of Manifests is woefully inconsistent. There are 5400
signed Manifests and the remainder unsigned. Who they are signed by is
unclear. Some I cannot even find on public key servers!)

3) Similar to what is done at keysigning parties, a hash of all Manifest
files would be generated and signed by the uber-key. This hash should be
generated from the actual portage tree prior to being propogated through
the mirror system.

Just an example, but I tried this in ${PORTDIR}

# find . -name "Manifest" -exec openssl dgst -ripemd160 {} ";" >MasterManifestFile.txt

(of course, gpg, md5sum, or related commands could be used. or a perl or
python substitute used. The above was just for illustration).

(where this master file gets stored is not settled now. I think it
should not be propogated, but kept off the mirrors. Others disagree. But
the concept is that it exists and gets signed)

4) When a user emerges an ebuild, he/she would check the hash of
the Manifest in the ebuild he or she is downloading against the
MasterManifestFile.txt file.

The rationale is that if Joe Bad Guy uploads a malicious ebuild to a
mirror he has access to, complete with a new manifest, it won't checksum
correctly against the master list, and the user can be protected. Having a
single hash of all Manifest files protects against intrusion into
parts of the distribution system. It also makes it OK for a user to download 
files that are not affected easily. And, since all directories would have
Manifests, and I would include profiles and eclass as well, they are
protected too.

And, since the MasterManifestFile.txt file is signed by the uber Gentoo
key, tampering with it would be difficult.

5) Every time a new file is added to the main tree, new Manifests must be
generated and a new master list created.

Essentially, what this scheme accomplishes is a double check on Manifests.
What it does not deal with is who signs each Manifest. I am not sure about
that. For example, some Manifest files are signed by now-revoked keys.
Some I can't find on keyservers. And, signing a Manifest file only does
not deal with all the other files. I'm not sure Manifests need to be
signed, but that's out of my realm of expertise and really is a policy
decision. I'm also not sure of the benefit of signing all files either.
Right now, signing of Manifest files is not enforced. How could you
enforce signing all files then?

Here's a snippet of what a Master file could look like using just one
directory, x11-base:

find -name "Manifest" -exec -ripemd160 \{} ";" | gpg --clearsign -

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

RIPEMD160(./xdirectfb/Manifest)= ca5398a78e9f92cff3c704255caec2b6589b0ccb
RIPEMD160(./xorg-x11/Manifest)= 527c1977c0e799aa41dbfa7e5ff3d4fa1026e8be
RIPEMD160(./x11-drm/Manifest)= 2836d93a85c0b7dcb58e3b2dc924d9bd9d8f8cf8
RIPEMD160(./xorg-server/Manifest)= 281e13187104e89525d081a92dc81b3e8b018dce
RIPEMD160(./kdrive/Manifest)= 2559c92f4a94063271959557bf6c084c4da03b53
RIPEMD160(./opengl-update/Manifest)= 534ec81aa9485b020c07cd7800fb60588d141e35
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEbvHJTTfGLUZ/v30RA5AKAKDJFRKIB3GwxYC4iUEVLMg+uuZ6gACgsIco
gSaCIOauDmFjtJNoK0f7bPs=
=Qm0N
-----END PGP SIGNATURE-----

A benefit of this scheme, is that instead of checksumming the thousands of
individual files in portage, we're only interested in the Manifests. The
entire tree of Manifests is <1Mb. Grepping a file would be fast, needing 
only the ebuild name and the word Manifest.

What would need to be determined is what checksumming method to use, and
to require gpg as a dependancy of portage so that signature verification
can be done on the Master File.

I also believe that live cds and other output from gentoo should be signed
as well. I looked at the 2006.0 cd and saw nothing on it.

Here's the Slackware approach that I am very familiar with. On the root
directory of each CD is a list of checksums called CHECKSUMS.md5. Pat
(Volkerding) then creates a detached signature of that file using the
Slackware Security Key. This way, the user can be assured that the list of
md5 checksums is authentic and check any file's checksum (or all) he/she
wants.

snippet of CHECKSUMS.md5

These are the MD5 message digests for the files in this directory.
If you want to test your files, use 'md5sum' and compare the values to
the ones listed here.

To test all these files, use this command:

md5sum -c CHECKSUMS.md5 | less

'md5sum' can be found in the GNU coreutils package on ftp.gnu.org in
/pub/gnu, or at any GNU mirror site.

MD5 message digest                Filename
3b6703583ac87b4ab8cd23aafadb1c2c  ./ANNOUNCE.10_2
470d6328592a31a8bed773e849317895  ./BOOTING.TXT
18810669f13b87348459e611d31ab760  ./COPYING
50aa19e2a2f983eca992d7775b11393c  ./COPYRIGHT.TXT
4e76de599428a3536b4e4e3288456d32  ./CRYPTO_NOTICE.TXT
f8f15922110049f42c8a1d3693e22272  ./ChangeLog.txt

peter@mars ~ $ gpg --search-keys Slackware\ Security
gpg: searching for "Slackware Security" from hkp server cryptonomicon.mit.edu
(1)     GUS-BR Security Team <security@×××××××××××××.br>
          1024 bit DSA key B181EC7C, created: 2004-11-18
(2)     Slackware Linux Project <security@×××××××××.com>
        Slackware Linux Project <security@×××××××××.com>
          1024 bit DSA key 40102233, created: 2003-02-26

Slackware publishes its uber key on public key servers for all to see. GUS
is authorized by Pat.

Gentoo can do similar with its output also.

Sorry. I said this would be brief, and I suppose I lied. However, I hope
someone might get a good thought or two from this (or a good laugh at my
naivete!). And thanks Patrick for helping with your feedback and getting
me to focus on some of these ideas a little more. HTH

-- 
Peter


-- 
gentoo-dev@g.o mailing list