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@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
