On Tue, Feb 8, 2011 at 5:43 PM, Denis A. Altoé Falqueto <[email protected]> wrote: > On Tue, Feb 8, 2011 at 8:02 PM, Dan McGee <[email protected]> wrote: >> On Tue, Feb 8, 2011 at 2:47 PM, Michael Seiwald <[email protected]> wrote: >>> (3) Repository Freeze Attacks >>> An attacker is able to prevent clients from updating by replaying an old >>> sync db file with a valid signature. This could be used to keep clients >>> from updating software with known vulnerabilities. >>> Solution: gpg-signatures already contain a timestamp. Before each >>> update, pacman could check if the timestamp is not older than a >>> specified period (e.g. a week). >> >> Yes, very well known, and the site I tell all people to have a read >> before hacking on this stuff: >> http://www.cs.arizona.edu/stork/packagemanagersecurity/ >> >> We will find a way to address this before we consider package signing >> complete. > > I remember some talking about that in the mailing list. It was > suggested to have a time limit for the validity of the database > signature, so the developers would have to generate a new signature at > least every n days, if the database didn't change. That would be a > worst case scenario, because the rolling release nature of Arch > generates lots of database updates and they would be signed very > often.
Allan and I are going to repeat this until our heads explode, but pacman != Arch Linux. What was that? pacman != Arch Linux. This needs to somehow be feasible for *everyone*, or at least not get in their way. I've had (although it has gone stagnant) my one-package eee kernel repo; I shouldn't have to sign that every 10 days if nothing changes, nor should some in-office repo providing a custom 10 packages or so, esp. if said database can be fetched from a reliable (HTTPS with valid cert, say) source. >>> (4) Signing keys >>> Currently when adding a signed package to the repository with repo-add, >>> the signature of the package itself (generated with the package >>> maintainers’ key) is included into the sync db (as %PGPSIG% field in the >>> desc file of the package). Afterwards, the updated sync db is also >>> signed. Firstly, we are not sure how this should be handled in practice. >>> Will the sync db be signed with a central repository key? Or with one of >>> the developers’ keys? Either way, the package signature in the sync db >>> (%PGPSIG%) adds no additional security value, because when pacman >>> verifies both the package signature and the signature of the sync db, it >>> uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the >>> signatures. >>> If an attacker can acquire a private key of any maintainer >>> he can generate valid signatures for every package and also for the sync >>> db. The more maintainers there are, the more private keys are around and >>> the bigger is the risk of a key being compromised. >>> Suggestions: there are different ways to improve the situation. One >>> possibility would be to remove the package signatures from the the sync >>> db and only sign the sync db itself with a central repository key on the >>> server. This is the way Debian does it. Of course this requires some >>> kind of system where the maintainers can submit their (signed) packages. >> So now you've opened up another can of worms, from what I see. If the >> database key was compromised, every package also has to be viewed as >> compromised or possibly tampered with. If 100 packages are signed with >> ~15 different keys, even if whatever key last signed the repository is >> compromised, we don't have to reverify any existing packages except >> those signed with the compromised key. >> >> So yes, there is the possibility of someone trying to resign every >> package, but that could be seemingly prevented or at least guarded >> against with smart backups and snapshots. >> >> No matter what, private keys should not be ending up on a central >> server (outside of maybe a repo-signing key)- that is too dangerous as >> you point out. > > Yes, that is really a problem. I agree that we should avoid putting > private keys on any server. We should base the solution on the concept > of web of trust, so that would not depend on any implementation in > Pacman. I mean, Pacman just trust the response given by gpg, that > will, in its turn, be based on the trust level and relationship of > keys defined by the final user (remember, we assume the users know > what they are doing and are the only ones responsible for their > system). > > I'm trying to devise an algorithm that could have the following properties: > > * must be run in the machine of the developer, so the private key > doesn't need to be kept in other places; > * must sign the packages that are stored in the server, to avoid > unnecessary file transfers At least in the "standard" development and packaging scenario, these first two things are happening on the developer's machine. I don't see too many cases where a developer should use a specific signing key on more than one machine; that way if some build machine key gets compromised it can be revoked without having to revoke all keys. If I am remembering GPG right. > * be not very different of repo-add, so the developers doesn't feel > demotivated to acquire a new habit Either people use it or don't, but enforcement comes via policy on this one- obviously our main repos will always have it, but I agree making it easy enough for everyone to want to use it is also a good thing. > If someone have some suggestions, please feel free to talk. >
