Em 09/07/2011 02:16, "Ben Walton" <[email protected]> escreveu: > > Excerpts from Maciej Bliziński's message of Fri Jul 08 13:06:39 -0400 2011: > > Hi Maciej, > > > Another thought: perhaps it would not be that hard to implement a > > POC of automatic catalog signing. For example: a machine in a > > private network, controlled by a trusted person runs gpg agent with > > a timeout in the order of 3 days to a week. A cron job running on > > that machine pulls the catalog file, signs it and pushes it back for > > the rest of the automation to pick it up. > > This is a good idea. I've been contemplating the design of such a > system for a few days now. > > > At this point, there is a problem, that there is no verification > > that the catalog pulled can be trusted. To fix that, we can > > I think something more 'on demand' is better suited here as that lends > itself to better atomicity which will be important. I'm thinking > something along the lines of: > > Just before a mirror push is about to happen, something opens a socket > to a daemon and says "please sign catalog current/i386/5.9 having sha1 > $sha1." The daemon would then grab the catalog from a preset > location, ensure the sha1 matches and sign it. > > The signature is then returned over the socket and the caller is > responsible for placing it appropriately with the files. > > Having things designed like this removes some possible security > issues. > > 1. If the client can only request catalog signatures based on the > tuple (catalog, arch, os release) and the daemon then goes and > reads the file from a run-time specified or hard coded directory, > the client cannot get 'just anything' signed. > 2. Making the client responsible for placing the signature data means > that, given 1, we don't need to protect the daemon with encryption, > authentication, etc, as getting a catalog signature for a valid > catalog is public data that will be available on the mirrors > anyway. It also removes privilege from the daemon so that it needs > read-only access to the data it will sign. > > If the client has enough access to manipulate the directory structure > that the daemon will read, it can make the daemon sign a manipulated > catalog. This level of compromise means things are already in bad > shape though, so it shouldn't be worse than the risks we have today. > > The daemon would, as you suggest, need a timeout so that a human needs > to re-initialize the agent storing the pass phrase periodically and it > could tell the caller if it was unable to perform signatures. > > I'm willing to code the daemon. > > With such a signing daemon in place, we can have a cron job running as > a dedicated catalog/mirror maintenance uid that has the access needed > to place catalogs and signatures and push to the live mirror area...It > will update catalogs, get them signed, etc. If the release proposal > is accepted, this job could also be the one that moves things from > unstable to current. > > As a side note, I'd like to mention to a wider audience than irc: I > think our signatures should be detached instead of clear signed. > These are nicer to work with all around. It would require > coordinating a pkgutil update though. > > > introduce signing of individual .pkg and .pkg.gz files. The script > > pulls not only the catalog file, but also the data files. It > > verifies that all files referenced in the index (the catalog file) > > are properly signed. If not, it complaints loudly. If yes, it > > proceeds with signing. > > This can be a separate topic, but I think it is something to look at. > The biggest hurdle here is ensuring that everyone gets a gpg key > created for this purpose and that we distribute the public portions of > the keys to client systems for verification. This could be tied into > CSWcswpki that I've already laid groundwork for. > > > The signatures could be uploaded with csw-upload-pkg. > > Detached signatures for this would be best too. > > > I do not have a good idea where to store the signatures. I can > > imagine an appendix to the catalog that lives in a parallel > > directory, or a subdirectory of e.g. unstable/sparc/5.9 > > CSWcswpki should pull them down and install them in a private keyring. > > > There also is the (independent) problem of key revocation, presented > > in detail by William in Dublin. > > Revoking a catalog signing key is different from revoking a maintainer > signing key. If we revoke a catalog key, we can regenerate a new > catalog with the new key. We may not be able to easily regenerate > signatures for all packages if the need arises. If we sign packages > individually, we may want to use a generic (but different than the > catalog signer) key for this purpose too. > > > The two stage implementation outlined above gives us the advantage > > that we can be back quickly and we can we have a plan how to improve > > the security chain between an individual maintainer and the user. > > Agreed. > > Thoughts?
Yes, here are some more. I like both ideas: the signing system initiating the connection (easier to secure it), and the buildfarm deciding when to sign. I have two alternative ideas. 1. The signing system listens, but the handling code is super simple, only sets a flag. Then the cron job notices it, and signing occurs. 2. The flag is set on buildfarm side, there is no listener on the signing side.
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
