On Thu, 5 Jun 2014, Miroslav Suchý wrote: > > Let us assume an attacker who got to the point where he or she would > > able to steal the key if it stayed on the build system [...] > Key will *not* be stored in build system. Just in Signing machine. Indeed. The conditional in question was counterfactual. > > obs-sign appears to record every operation but [...] > I plan to record hash *and* filenames. Which should be enough for > forensics analysis. Filenames will probably make log records more readable but they are not included in signed data and any data can be signed under any name. But the things are even worse: an insidious attacker might inject a Trojan horse into a build initiated by a legitimate user. (*) (*) It seems to me Copr and Mock (well, Mock seems to be the primary offender here) are quite happy to pull sources & additional repos for the build environment over cleartext HTTP with no integrity checks. And users are encouraged to configure it that way. Therefore one might be able to plan a Trojan horse into a signed package without breaking into the Copr backend. Have I missed anything? Also: Who will (be able to) review the logs? > Storing whole data payload is not possible (read it as "we have no money > for that"), because we plan to build and sign (docker) images as well. I agree. It would be, ahem, too excessive to store full images. Would it be possible to extract and store the list of contained files and their properties that would allow one to compare the result with a build created elsewhere? (Of course, this assumes the build process is reproducible--to a sufficient degree.) > No money for that. Man, you talk like a manager. ;) On Thu, 5 Jun 2014, Matthew Miller wrote: > At one of my previous jobs, we planned but never had to use an approach > for this: an update to the '-release' RPM which included a post script > to remove the compromised key from systems. That would probably work. But it might lead to serious confusion: The update would need to be signed with the old compromised key, while all other new packages would be signed with the new key. (An RPM file could carry multiple signatures of the same type but I am afraid the program would not be able to handle them.) Anyone will have to install the update to *-release *after* any older updates (assuming they have not been re-signed with the new key) and *before* any newer updates (including older updates that have been re-signed and any newer updates to *-release itself). I can imagine how an attempt to replace the signing key that way could result in many systems in an inconsistent state, requiring a manual intervention to recover. On Thu, 5 Jun 2014, Simo Sorce wrote: > The problem is not just the compromised key, but compromised packages, > though I guess you could re-sign all packages, but then you also have to > ship those signatures out of band (you cannot force people to re-install > all packages right ?). Do you have to ship the new signatures to anyone? Does anyone re-check signatures of packages that have already been installed? > One way to mitigate the impact is also to create subkeys (say one every > week) so that you can "repudiate" a window of time by marking only a set > of subkeys as compromised. This requires a more complicated signing and > verification process though. You have a problem. You implement PKI to solve the problem. Now you have two problems... I am sorry, I could not resist. :) All right, I am going to be (mostly) serious again. Some kind of (nontrivial) PKI is probably desirable. On Thu, 5 Jun 2014, Bruno Wolff III wrote: > Didn't we do something like this in response to: > https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html Hmm... the announcement links to <https://fedoraproject.org/wiki/New_signing_key> and that page outlines a 13-step plan where step number 12 is as follows: During development and release of Fedora 10, consider and create better ways to handle automatic key migration. (in progress) I guess that part of the plan has not made much progress since 2009. -- Pavel Kankovsky aka Peak "Que sais-je?" -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
