On Tue, Feb 8, 2011 at 5:43 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Tue, Feb 8, 2011 at 8:02 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Feb 8, 2011 at 2:47 PM, Michael Seiwald <michael@mseiwald.at> 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.