Re: [gentoo-dev] Re: [gentoo-security] Verifying portage is from Gentoo

[Sven Vermeulen]

On Mon, Jan 13, 2003 at 01:34:31PM -0500, Dylan Carlson wrote:
> [2] Gentoo project managers need to kill off inactive developers, and
> regularly hold key-signing parties.

This is IMHO difficult since the developers are from all over the world. You
would have to have local KSP's, then have a trusted party go over to the
other countries (or continents) so that by trusting that party all users can
verify the validity of the keys.

> Having the developer sign each ebuild before a commit will minimize these
> risks.  If a dev's box is rooted -- the hacker can commit as many hacks as
> they want to the Gentoo CVS tree, but the ebuilds will not be signed, and
> consequently will be ignored on the Gentoo clients.
>
> That is why I'm saying one key sign for the whole tree is a bad idea...

It won't harm to have a second signature :)

My take on this security-aspect (a possible, but probably paranoid solution):

The way in which you trust everything begins at the installation-process of
the Gentoo Linux distribution. Do you trust the stage-tarballs or provided
Gentoo Linux ISO's? To be able to trust those, you will have to check the
validity of these files on your current operating system using some tool
(let's say a OpenPGP-supporting client). This /assumes/ you trust your
current system. If you do not, all things are invalid. 

So before the paranoid user installs Gentoo Linux using the ISO or tarballs,
it will have to check the validity of those files. So the first "barrier" is
a signed .iso or .tgz. Lets say the key is of the Gentoo Developer in charge
of releases. The paranoid person downloads the public key from a PKI, checks
the fingerprint from several locations (gentoo.org, #gentoo, mirrors, the
developer himself (this will make him go nuts, but hey, what are developers
for :), ...) and/or see if the key is trusted by someone he trusts.

Okay, when this is done, he burns the .iso on the CD (I assume here that he
installs it using the CD, if he doesn't, he will have to make sure that his
own system provides the same tools as the CD, but this shouldn't be a
problem) and boots.

The next security-aspect is the security of the livecd. If I am not mistaken
there are no daemons on the livecd, and if there are, they should only listen
to the localhost address per default. Perhaps a firewall blocking all
incoming connections could be used, but this should be done with care.
Firewalls are only good if they are configured correctly. If not, they are
more harmfull then harmless...

When the stage1 tarball is installed, the first thing that is done is an
"emerge sync". So here lays the next security issue. We will have to make
sure that whatever is downloaded into the Portage tree is trusted. Since the
emerge-tool itself is trusted (it is contained on the .iso or .tgz) we could
have it check for validity. So one implementation is to have Portage support
OpenPGP. Lets say it uses pyme (a Python interface to GPGME) so GnuPG and
GPGME are also in stage1 (this increases the download ofcourse). It syncs its
tree with the remote mirror. 

Now there are several ways to implement a secure way of handling the ebuilds,
most of them have passed the revue. One way of handling (with many thanks to
the ppl that proposed and discussed this):

1/ Digitally sign each ebuild. This means that all developers have to sign
   their ebuilds, and that they manually check every proposed change in the
   bugzilla. 
	Problems:
		- This is a very intensive process and still not completely
		  secure. The downloaded files could be malicious (cf.
		  sendmail ftp-server hack) but this is something we can't
		  do anything about. We will have to trust the official
		  ftp-servers of the tools. 
   This also means that all developers' keys are available on the .iso.
   Portage will have to check the signature of every ebuild he wants to
   emerge.

2/ Implement the proposed timeframe. If a tree has not been updated for over
   x hours, warn so that the person can re-emerge with another mirror. Use a
   (one or more) filelist(s) which give the latest mtime of each file or
   directory. Implement this properly. I personally don't know how rsync
   works, so I can't elaborate on this any further. Digitally sign these
   files. Because of the nature of this signing, it should be done
   automatically (it is impossible to have a developer checkout a cvs tree,
   create the necessary filelists, signing all of them and then upload the
   whole tree to the server. This is overkill and imposes lots of new
   problems). So have the main server (or the CVS server) do this (CVS: only
   when a tree is pulled out and placed on the FTP, or FTP: only when
   uploading occurs).
   	Problems:
		- This assumes we trust the CVS- or FTP-server as we do with
		  www.kernel.org. Leave it this way. Users and developers
		  will soon see if there is something wrong, since the
		  Gentoo Development is very active. If you really want, you
		  can have an audit team regularly check if all current
		  ebuilds on the main server resemble the currect versions
		  of the tools. We should also remove vulnerable ebuilds from
		  the server. If one users sees that there is a vulnerable
		  version, he can report it.
   Portage will have to check the validity of the filelists with his tree
   (checking the signature of the filelists in general) and the mtime of the
   ebuilds he wants to emerge. 

3/ Have Portage individually register every removal of the Portage tree. If
   an ebuild has been removed, register it in, f.i. "removed-ebuilds". If for
   some reason that ebuild is available again, give a warning. 
   Since Gentoo doesn't remove "old" ebuilds, the policy of removing only
   vulnerable ebuilds or ebuilds that won't work (because the tarball itself
   is removed) helps in this aspect: ebuilds that return from /dev/null are :
	- risky (a mirror that provides a vulnerable ebuild)
	- strange (the previous mirror that removed a non-vulnerable ebuild)
   The first reason is the reason why this should be implemented. The second
   reason, well, I really don't know why a hacker would remove a
   non-vulnerable ebuild if he knows the vulnerable ebuilds are removed as
   well. But hackers are weird, so even if this happens, this means that
   there is something "wrong" (CVS- or FTP-server hacked). Don't forget that,
   if the mirror just provides vulnerable ebuilds (or remove non-vulnerable
   ebuilds) without having a hacker at service that hacked the CVS- or
   FTP-server) then the filelists will be out-of-sync and Portage will warn
   you of that.

4/ Make the use of sandbox installs mandatory. Using this sandbox, we can
   easily trap trojans that are activated during the ./configure-steps, as
   occur often. 

I think this is an implementation that has a realistic approach (if what I
heard on the mailinglist, that the Gentoo-developers have no problems with
signing the ebuilds, is true). This doesn't impose restrictions on who can be
a gentoo mirror, which is - in my vision - a good thing. Mirrors shouldn't be
restricted; the more the better. 

This makes the installationprocess rather secure (more than it is now). If
you want to secure your installation itself, read the Gentoo Security Guide.

Now go ahead and shoot holes in this one :) 

Wkr,
	Sven Vermeulen

-- 
	Fighting for peace is like fucking for virginity.