Time to resurrect multi-key signatures in RPM?

Nils Philippsen nils at redhat.com
Wed Aug 27 10:30:22 UTC 2008


On Tue, 2008-08-26 at 11:33 +0000, Bojan Smojver wrote:
> Nils Philippsen <nils <at> redhat.com> writes:
> 
> > builds between
> > separate build systems (that have different profile data) will
> > inevitably differ.
> 
> That is a problem, I admit.
> 
> > Second, it makes the update system more vulnerable to DOS attacks,
> > insofar as it only takes an attacker to hack himself into one of the
> > signatories to produce bad signatures on updates he wants to block (if
> > they e.g. contain security fixes). The risk of this is at least
> > proportionally higher with multiple targets to choose from (think RAID-0
> > and what it does to the probability of errors in such a set of disks).
> 
> If a signatory is producing bad signatures, just use another one. It is trivial
> to discard packages signed by bad keys. It is also trivial to ask another
> signatory from the pool to check and sign instead.
[snip]

But that's not what you described in the original posting (emphasis on
"no bad ones"):

"""
> With this we could then require N good signatures (and no bad ones) on
> each package before yum would trust the content.
"""

> > Third, unless a signatory runs his own build system to verify package
> > builds (and disregarding my first point), his signature doesn't have
> > much value as he has to rely on the checksum data provided by the
> > package maintainer in his signed email -- which relies on the build
> > system not being compromised to begin with.
> 
> That is also not true. If the signatory receives a signed e-mail from the
> packager with checksums in it (i.e. rpm -qp --dump, as per sv), the signatory
> can verify that against someone else's build system that is not publicly
> writeable (e.g. Matt's at Dell). Not everyone would need to run their own.

The Matt or whoever else has a separate build system are the only
valuable signatories. Anybody else can only say "me too" but that
doesn't add anything to the trust value.

> And remember, the attacker would have to break the build system _and_ fake the
> signed e-mail from the packager AT THE SAME TIME and then get signatories to
> sign without any checking. Much less likely then just compromising the build
> system (which is what they can do now).

No, without independent verification builds, an attacker just has to
break the build system because a normal packager has no (sensible) way
to tell if e.g. a compromised compiler inserted trojan code into the
executables. Thus, a normal packager -- trusting what comes out of the
build system -- would just sign off whatever the resulting package is.

As independent verification builds aren't the deterministic thing that
you seem to think, that doesn't sound very helpful to me.

> It is better to check against something then not to check at all, IMHO.

It's like with spam filtering: bad positives are really bad. Do you
think repeating the hoopla of the last days just because of a bad
positive caused by a fluke in an independent build system we have no
control over is a good thing?

> You know, maybe this would be a good opportunity for some cross-distro
> cooperation. They could build our stuff on their build farms, we build their
> stuff on ours (not everything - just updates). Then attackers need to compromise
> all in order to get just one scalp. Quite an effort.

Our packages built in say OpenSUSE's or Ubuntu's build system will
differ from what koji spits out, with a probability bordering on
certainty. I don't know what that gains us.

> > Then there's the additional burden on maintainers -- yet another
> > bureaucratic hurdle.
> 
> Yeah, security is always like that - pain in the arse. I still remember some
> devs in the office chmod-ing everything to 777 because "it's easier" :-)

I can live with PITA as long as there's a tangible benefit from it. I
don't see that here -- just because something is a pain in the arse, it
doesn't necessarily improve security.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011




More information about the devel mailing list