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