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

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

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 789 bytes --]

On Monday 13 January 2003 09:13, cdfrey@netdirect.ca wrote:
> [snip]
>
> > But there are more easy ways to do this.
>
> Yeah... the idea that this is so easy to do is a little scary.  I assume
> even the developers do "emerge rsyncs" over the internet (I could be
> wrong here), so there is a possibility for a trojan to silently work
> it's way through the entire Gentoo world from the developers down.
>
> I'm happy to see my comments weren't just brushed aside.  Many thanks!
>

Maybe the easiest way would be that some/all rsync mirrors would offer rsync 
over ssl, so that the origin servers could be authenticated. This would also 
mean some changes for clients to be able to use it.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Evan Powers]

On Monday 13 January 2003 05:24 am, Paul de Vrieze wrote:
> Maybe the easiest way would be that some/all rsync mirrors would offer
> rsync over ssl, so that the origin servers could be authenticated. This
> would also mean some changes for clients to be able to use it.

I think something does have to be done about this.

There was a discussion about this (which I took part in) on gentoo-user and 
then the gentoo forums. For those who are interested:

http://forums.gentoo.org/viewtopic.php?t=26137

Personally, I think it's better to cryptographically sign the portage tree 
somehow at the source, then distribute it in the current manner. This method 
has the advantage that we need not implicitly trust the rsync mirror admins 
(as we currently do) and that the tree is immune to man-in-the-middle attacks 
as it is transfered between official site and mirror or between mirror and 
client. Secure rsync (via SSL or whatever) doesn't completely solve the 
problem.

That said, there's many ways of signing the portage tree. I advocate having 
the master rsync server automatically sign the tree as it checks out the CVS 
tree. There's been a lot of talk at various times about developers signing 
ebuilds individually, but I'm not sure that actually gains us anything. I 
also advocate building a time-dependence into the signatures. Read my forum 
posts for my complete musings on the matter, but here's a summary of my 
points:

1) An authentic but out-of-date tree can be just as dangerous as a inauthentic 
tree.
2) CVS works against per-developer signing of ebuilds. Consider "$Version: $", 
etc.
3) Ultimately we are forced to trust CVS, so we can't realize any additional 
security from per-developer signatures.

I present a method for efficiently signing the portage tree at the source 
while avoiding, to some extent, the race-condition type pitfalls of rsyncing 
while changes are in progress, etc. Read my forum posts for details.

I don't pretend to know everything about this sort of thing, so comments are 
very welcome.

Evan Powers

--
gentoo-dev@gentoo.org mailing list

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

[Dylan Carlson]

On Monday 13 January 2003 12:27pm, Evan Powers wrote:
> On Monday 13 January 2003 05:24 am, Paul de Vrieze wrote:
> > Maybe the easiest way would be that some/all rsync mirrors would offer
> > rsync over ssl, so that the origin servers could be authenticated.
> > This would also mean some changes for clients to be able to use it.
>
> I think something does have to be done about this.
>

I agree, but FWIW, the BSDs have had unsigned ports for a long time without 
any serious issues.  How complex is this issue, really?

* gnupg must be installed for every user, and special practices will have 
to go into place to protect gnupg from tampering.  (achilles)

* a publically available web of cross-signed public keys needs to be made 
available, with the keys also available on MIT's keyserver for sanity.

* each dev signs the ebuild with his/her public key before it gets 
committed.  

> Secure rsync (via SSL or whatever) doesn't completely solve the 
> problem.

cvsup and rsync can use SSL via stunnel.  I would like to see Gentoo use 
cvsup for efficiency/bandwidth reasons instead of rsync.

Traffic encryption is only useful to minimize risk of man-in-the-middle 
attacks/dns hacks/etc... which all said and done, is rare.  IMO this 
should be the last priority.  

>
> That said, there's many ways of signing the portage tree. I advocate
> having the master rsync server automatically sign the tree as it checks
> out the CVS tree. 

Single point of failure, I don't like this idea in the sense of 
server-->clients.   That key would have to be updated constantly, and if 
it gets compromised, everything is compromised by way of assumption.

However -- I see this as being valuable in replicating the master tree to 
other mirrors, though, where the pubkeys are known only to the master and 
its mirrors.  That's if you're using rsync.

cvsup uses authentication keys to mirror.

> 2) CVS works against per-developer signing of ebuilds. Consider
> "$Version: $", etc.

We should take the CVS keywords out of the ebuilds.

> 3) Ultimately we are forced to trust CVS, so we can't realize any
> additional security from per-developer signatures.

I'm not sure that the ultimate problem is CVS... it's human beings.  If you 
don't have an account with the right keys on the CVS box, you're not doing 
updates.  It's that simple.

If people are using ssh keys without passphrases, someone can take over a 
dev's box and do all the nastiness they want to on Gentoo's CVS server.  
That's not the fault of CVS or SSH.  

[1] Dev's have to generate their keys properly, and keep their machines 
secure.
[2] Gentoo project managers need to kill off inactive developers, and 
regularly hold key-signing parties.

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...

This is some good conversation...

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

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

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 7531 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Evan Powers]

On Monday 13 January 2003 01:34 pm, Dylan Carlson wrote:
> 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.

I'm going to draw upon Sven Vermeulen's well-reasoned comments (Tuesday 14 
January 2003 04:22 am, same email subject) here.

Let's assume the developers are using CVS-over-ssh and that they're using 
public keys (with good passphrases) to authenticate.

From the developer's perspective, having to sign ebuilds is redundant. By 
logging in with his public key, he's already proven his identity to the 
server. The CVS server can't gain any additional security from a signature. 
It's already 100% certain the developer is who he says he is, and the 
encrypted channel proves that the data is unaltered.

A hacker who roots the dev's machine can't do squat, because he doesn't know 
the passphrase. And if he can discover one passphrase, he can probably 
discover the one protecting the dev's signing key, so signing still won't get 
you anything.

Now, the question is how rigorously we want to pass on this information to the 
next link in the chain, a client or mirror connecting to the CVS server.

On Tuesday 14 January 2003 04:22 am, Sven Vermeulen wrote:
> 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.
[...]
>    	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.

I'm with Sven on this one. While having the dev's sign ebuilds allows the 
theoretical advantage of allowing the client or mirror to ascertain validity 
without trusting the CVS server, I think the practical advantages of this 
approach are very small.

1. It's a lot of work.
2. Signatures are unlikely to interact well with the various behind-the-scenes 
actions of CVS. (Such as keywords like $Version: $.)
3. Because commits of multiple files are not atomic with CVS, it'll be very 
difficult to associate a signature with the correct file version. There's 
nothing associating the two versions within their RCS files. Furthermore, it 
becomes possible for one user executing a CVS checkout to get a new file with 
the old signature, or vice versa. Since the CVS server has a lot of activity, 
I would expect such events to happen often enough to be quite annoying.

On Tuesday 14 January 2003 04:22 am, Sven Vermeulen wrote:
> 3/ Have Portage individually register every removal of the Portage tree.

A better thing than a separate removal registry is to roll the functionality 
into the mtime and signature files that are already present. If a file isn't 
mentioned, it's presence is an error.

In the forum discussion at http://forums.gentoo.org/viewtopic.php?t=26137, I 
discuss a framework which describes how this could be done.

Comments anyone?

Evan Powers

--
gentoo-dev@gentoo.org mailing list