Re: [gentoo-dev] Redux: 2004.1 will not include a secure portage.

[Robin H. Johnson]

On Thu, Mar 25, 2004 at 09:24:37AM +0100, John Nilsson wrote:
> On Thu, 2004-03-25 at 02:45, Robin H. Johnson wrote:
> > OK, after reading this entire thread, I've been thinking about a usable
> > implementation from both the administrative and developer perspective.
> > One of the most important things to remember in designing this, is that while
> > you can prevent damage from most individual attacks, no system in existence can
> > withstand a multi-faceted all-out assault.
> >
> > Goals:
> > ------
> > - protect against compromised developer box / rogue developer
> > - protect against compromised rsync server
>
> Exactly how secure are we aiming at? The schemes presented here does
> nothing to secure gentoo boxes from malicious source code.
That is completely not the intent of this system. This system is
intended to stop tampering with the portage tree. The portage tree is
dangerous in it's nature of being executable shell.

As an example, open up the latest version of some ebuild and at the very top
add in: "echo bang", now run an emerge operation, say 'emerge -p
package' where package uses the ebuild that you just modified, and see
emerge throw 'bang' out on your screen. If you aren't running with
FEATURES=userpriv, you're could be in for a world of trouble here (and
even userpriv can be circumvented). A malicously inserted 'rm -rf / &'
or MUCH worse.

> If a patch is signed, with a good signature, does that mean that the
> signers has audited the patch for security holes?
While this is a laudable goal, the amount of patches going thru the
system make this impossible in some cases. I can say for example that I
have reviewed _every_ patch that is used with qmail (which I maintain).

> What is to say that the source compiled with an ebuild is not
> compromised?
Verifying that an application has not been tampered with is an
end-to-end process. As an example, our digests on source tarballs allow
us to detect tampering on a gentoo mirror or upstream, provided we know
that the source was in a good state to start off with. I usually do
verify that a source tarball has a good md5sum with a gpg signature if
one is available (in many cases it isn't).

> Of course we should do our part to make a secure transaction of
> source, but the costs has to be weighted to the gains. Any security
> scheme must be virtually transparent to the developers or it is not
> worth it, until we can secure the actual code.
My proposed setup is transparent to developers in all but one way: the
possible case that developers don't use an agent to store their GPG
passphrase and need to enter it to commit (or have a in-memory timeout
for security with an agent).

-- 
Robin Hugh Johnson
E-Mail     : robbat2@××××××××××××××.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85