Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

On Thu, Aug 18, 2005 at 08:59:43PM -0500, Jeremy Blosser (emrys) wrote:
> On Aug 18, Seth Alan Woolley [seth AT positivism.org] wrote:
> > On Fri, Aug 19, 2005 at 01:08:01AM +0200, Karsten Behrmann wrote:
> > > On Thu, 18 Aug 2005 09:21:53 -0700, Andrew wrote:
> > > > Good point. Its also (potentially) a security risk, since if the key
> > > > was described as ../../kernels/linux/foo.gpg, if the key wasnt found
> > > > there (say it was renamed or moved) the code would look in the 
> > > > grimoire
> > > > directory with that path appended to it. In that case it would look
> > > > outside the grimoire into a possibly unsecured directory, the spell 
> > > > would
> > > > use an incorrect gpg key and validate a possibly compromised 
> > > > source/sig.
> > > > Unlikely, but worth mentioning.
> > > 
> > > Apropos security risks in gpg signing:
> > > Just a thought, I'm almost sure it has to be resolved, but I thought 
> > > I'd mention it: Do we specify a keyring as well as a signer's 
> > > fingerprint or at least ID? Otherwise, couldn't the new gnu dev that 
> > > just got into gnu.gpg sign off a compromised binutils? The basic point 
> > > here is that maybe we should keep the keyrings as collections to be 
> > > referenced, but not as authorities on their own.
> > 
> > They have access to our source code repository, too.
> 
> He said gnu.gpg, not gurus.gpg.
> 

Hah, I totally misread that.

> For someone to compromise an app that's referencing the gnu.gpg keyring for
> signature checking THROUGH the keyring, they would need to:
> 
> 1a) get control of an existing key inside of gnu.gpg that we have already
> decided is ok to use
> OR
> 1b) get a new key inside of gnu.gpg and get us to accept it
> 2a) compromise the tarball
> AND
> 2b) generate a compromised signature for the tarball and get it published at
> the SOURCEn_URL we're using to get the release signature
> 
> 1a) is out of our control, it is solely determined by the access security
> around the private half of the relevant keypair.
> 1b) is a risk in any system like this and it's the main thing that we need
> to worry about.  We need to make sure we only use keys that are good.
> However, to your point, no, some new gnu dev wouldn't automatically have us
> using their key, we'd have to add it to the version of that keyring that
> we're using.  If/how we add it is the subject of the recent threads around
> how we verify keys.
> 
> 2a) and 2b) are out of our hands as well, and it's worth noting that if the
> upstream security breaks down to the point that an attacker has control of
> the release tarball AND the private signing key, we can't do a thing about
> it.
> 
> Our integrity checks are designed to catch the "normal" situation where
> someone gets control of the upstream distribution site and replaces the
> tarball with a compromised one.  If they only manage this much, the
> signature check will fail, and we'll see it.  They may also try to replace
> the signature on the upstream server, but unless they have the private key
> needed to generate a real signature using a key in the local keyring we're
> referencing, we're going to notice that as well.
> 
> If they manage to compromise the tarball and still get upstream to sign it
> we also can't do anything.  Remember, we aren't guaranteeing the source
> isn't trojaned or going to run rm -rf /, we're just verifying it's the same
> tarball that upstream released.

Totally correct.

Seth

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454  E082 99F0 69DC FDCE E733

Attachment: pgpMp1js54kF6.pgp
Description: PGP signature