On Sat, 2009-01-17 at 10:31 -0500, Steve Grubb wrote: > On Saturday 17 January 2009 10:19:21 am Douglas E. Warner wrote: > > On 01/16/2009 Jesse Keating wrote: > > > Given that we can't revoke, yes, we plan to use new keys each release. > > > We can use gpg web-o-trust thing and sign the new keys with the old > > > keys and whatnot, does that actually help people? > > > > Why couldn't we revoke keys? Even if RPM itself doesn't have the > > capability, we could have yum periodically check for updates on installed > > keys on keyservers through a plugin, I would imagine. > > I have a machine that has been migrated for a long time. It has 9 > gpg-pubkey packages installed. Which ones are valid? Why don't they get > retired by obsoletes or something? Could someone use my ancient gpg-pubkeys > as a basis for an attack on repo metadata > (http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html) > and provide an older package with known security holes? If an attacker has broken a key you have installed, they can just sign bad rpms ... no need to just attack via. munged metadata (which has other protections). > Old keys should be retired. We should also make import of keys an auditable > event. There are a few things to take into account: 1. You can use the yum-keys plugin to look at the installed keys, and remove old ones. 2. Yum is moving to have all GPG operations outside of rpm. We currently have repo_gpgkey, and we'll eventually make gpgkey be per. repo too (so you can't have rpmfusion rpms auto. installed from the fedora repo. ... or whatever). 3. Yum can run as non-root, as can rpm ... so due to the design of audit you can't use that. 4. rpm/yum run as root with full SELinux privs. for the package DB and installing anything. Thus. from a realistic security POV installing any rpm is on the same level as installing the GPG keys. Thus. it's worthless to just "audit" GPG key installs. Putting audit file watches on everything in /var/lib/rpm is probably the only viable solution, although adding something else might give a better "ui" (but unless done very well this will be misleading as people might only watch for the "nice ui" audit messages, and thus. be vulnerable). -- James Antill <james@xxxxxxxxxxxxxxxxx> Fedora -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
