1:34 p.m.
Currently we have two gpg keys per release, one for
rawhide/updates-testing and one for the final release and stable
updates. This complicates a number of things and I'm really wondering
what is the real actual value we get out of having multiple keys per
release? I have some ideas that I'm going to keep to myself for right
now, but I'd like you, the consumers to help me understand what value
you see in it, and if that value remains if we were to have a key we
applied to all koji builds as the happen which is different from the
'release' key we'd use at release time and updates(-testing?) time for
each release.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:16 p.m.
Jesse Keating wrote:
Currently we have two gpg keys per release, one for
rawhide/updates-testing and one for the final release and stable
updates. This complicates a number of things and I'm really
wondering what is the real actual value we get out of having
multiple keys per release? I have some ideas that I'm going to keep
to myself for right now, but I'd like you, the consumers to help me
understand what value you see in it, and if that value remains if we
were to have a key we applied to all koji builds as the happen which
is different from the 'release' key we'd use at release time and
updates(-testing?) time for each release.
One advantage (which may or may not be enough to warrant keeping the
keys separate) is that if you want to ensure no packages from
updates-testing are installed on a box, you can easily do so by not
importing the testing key. I don't think any of the tools
automatically import keys without prompting, the user, correct?
I'm more curious whether the plan going forward is to generate a new
key for each release or if that was just a temporary situation due to
the infrastructure intrusion last August. I think it adds a little
bit of confidence when the signing key remains the same for a
reasonably long time (certainly more than the life of one release).
On the other hand, the lack of any way to revoke a key in the rpm db
is problematic and cycling the keys once per release does mitigate
this a little.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Life is the art of drawing without an eraser.
-- John Gardner
2:38 p.m.
On Fri, 2009-01-16 at 15:16 -0500, Todd Zullinger wrote:
One advantage (which may or may not be enough to warrant keeping
the
keys separate) is that if you want to ensure no packages from
updates-testing are installed on a box, you can easily do so by not
importing the testing key. I don't think any of the tools
automatically import keys without prompting, the user, correct?
That's correct. We could still accomplish this by having
1) a key that is applied to any build that comes from an official koji
build.
2) Only apply a releases key to a package that was in the GOLD release,
and those packages which migrate to stable updates.
If you don't trust the koji key, you'll only ever get something that has
been "blessed" by a human.
I'm more curious whether the plan going forward is to generate a
new
key for each release or if that was just a temporary situation due to
the infrastructure intrusion last August. I think it adds a little
bit of confidence when the signing key remains the same for a
reasonably long time (certainly more than the life of one release).
On the other hand, the lack of any way to revoke a key in the rpm db
is problematic and cycling the keys once per release does mitigate
this a little.
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?
I guess we really need to understand what it is that signing gives us.
At a basic level, the gpg signature says that "this package came from
Fedora". That has an extreme amount of value to it, as you state you
can trust only that key (set) and get only packages that came from
Fedora. We've tried to go a bit further and apply status to the keys to
indicate "this is a test package that came from Fedora" vs "this is a
stable package that came from Fedora", to allow you to get even more
fine tuned with your trust.
Is there anything else we're getting out of these keys?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
9:23 p.m.
Jesse Keating wrote:
On Fri, 2009-01-16 at 15:16 -0500, Todd Zullinger wrote:
> One advantage (which may or may not be enough to warrant keeping the
> keys separate) is that if you want to ensure no packages from
> updates-testing are installed on a box, you can easily do so by not
> importing the testing key. I don't think any of the tools
> automatically import keys without prompting, the user, correct?
>
That's correct. We could still accomplish this by having
1) a key that is applied to any build that comes from an official koji
build.
2) Only apply a releases key to a package that was in the GOLD release,
and those packages which migrate to stable updates.
If you don't trust the koji key, you'll only ever get something that has
been "blessed" by a human.
> I'm more curious whether the plan going forward is to generate a new
> key for each release or if that was just a temporary situation due to
> the infrastructure intrusion last August. I think it adds a little
> bit of confidence when the signing key remains the same for a
> reasonably long time (certainly more than the life of one release).
> On the other hand, the lack of any way to revoke a key in the rpm db
> is problematic and cycling the keys once per release does mitigate
> this a little.
>
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?
I guess we really need to understand what it is that signing gives us.
At a basic level, the gpg signature says that "this package came from
Fedora". That has an extreme amount of value to it, as you state you
can trust only that key (set) and get only packages that came from
Fedora. We've tried to go a bit further and apply status to the keys to
indicate "this is a test package that came from Fedora" vs "this is a
stable package that came from Fedora", to allow you to get even more
fine tuned with your trust.
Is there anything else we're getting out of these keys?
I think its wrong to get the latter out of the keys (though the right
way might mean touching rpm in a way we aren't allowed/able to). Once we
have "This package came from Fedora" then for the rest of the info, we
can just state it in a package header. If the headers are signed then we
have the necessary level of security. We only need one key to provide
the non-refutability. The rest of the information can just be stated.
--CJD
9:45 p.m.
On Fri, 2009-01-16 at 22:23 -0500, Casey Dahlin wrote:
I think its wrong to get the latter out of the keys (though the
right
way might mean touching rpm in a way we aren't allowed/able to). Once we
have "This package came from Fedora" then for the rest of the info, we
can just state it in a package header. If the headers are signed then we
have the necessary level of security. We only need one key to provide
the non-refutability. The rest of the information can just be stated.
I'd rather state that in the repodata, rather than the rpm itself.
Stating it in the rpm would mean changing the rpm file between -testing
and updates, which would break the ability to hardlink, and would mean
unnecessary churn.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:38 p.m.
Jesse Keating wrote:
On Fri, 2009-01-16 at 22:23 -0500, Casey Dahlin wrote:
> I think its wrong to get the latter out of the keys (though the right
> way might mean touching rpm in a way we aren't allowed/able to). Once we
> have "This package came from Fedora" then for the rest of the info, we
> can just state it in a package header. If the headers are signed then we
> have the necessary level of security. We only need one key to provide
> the non-refutability. The rest of the information can just be stated.
>
I'd rather state that in the repodata, rather than the rpm itself.
Stating it in the rpm would mean changing the rpm file between -testing
and updates, which would break the ability to hardlink, and would mean
unnecessary churn.
That works too. The point is we shouldn't be using keys to categorize
things. Only to authenticate them. And the only reason to have more than
one key is to limit the effects of one of the keys being compromised
(the all-your-eggs-in-one-basket issue).
--CJD
9:19 a.m.
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.
-Doug
9:31 a.m.
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...)
and provide an older package with known security holes?
Old keys should be retired. We should also make import of keys an auditable
event.
-Steve
10:59 a.m.
On Sat, 2009-01-17 at 10:31 -0500, Steve Grubb wrote:
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?
We explored these options after the incident. Last I heard the only
current way this is going to work is if an updated rpm package is
released that has a hardcoded distrust of the keys that might have been
compromised. However I do believe it's on their roadmap to revamp how
keys are used so that we could revoke or expire keys, regardless of
where they come from.
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...)
and provide an older package with known security holes?
Old keys should be retired. We should also make import of keys an auditable
event.
Are not all rpm actions audited? Importing a key essentially installs
it into the rpm database.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:50 p.m.
On Saturday 17 January 2009 11:59:09 am Jesse Keating wrote:
We should also make import of keys an auditable event.
Are not all rpm actions audited?
No. What I'm talking about is perhaps defining a specific audit event type
that would signify that a key was imported and where it came from. I've seen
cases where rpm tries to download keys from the network. This is one of the
few security sensitive actions that is not put into the audit system.
-Steve
1:41 a.m.
On Sat, 17 Jan 2009, Steve Grubb wrote:
On Saturday 17 January 2009 11:59:09 am Jesse Keating wrote:
> We should also make import of keys an auditable event.
>
> Are not all rpm actions audited?
No. What I'm talking about is perhaps defining a specific audit event type
that would signify that a key was imported and where it came from. I've seen
cases where rpm tries to download keys from the network. This is one of the
few security sensitive actions that is not put into the audit system.
FWIW, rpm >= 4.6 will never try to download keys from the network unless
explicitly told to do so with --import. Only 4.4.x has the "feature" to
automatically try and fetch unknown keys from public keyservers, and from
4.4.2.1 onwards that's disabled by default (and every vendor has disabled
it in their packages for affected versions anyway)
- Panu -
1:07 p.m.
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...)
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(a)fedoraproject.org>
Fedora
12:39 p.m.
On Fri, 2009-01-16 at 15:16 -0500, Todd Zullinger wrote:
One advantage (which may or may not be enough to warrant keeping the
keys separate) is that if you want to ensure no packages from
updates-testing are installed on a box, you can easily do so by not
importing the testing key. I don't think any of the tools
automatically import keys without prompting, the user, correct?
yum-cron will automatically import the key if you enable
updates-testing, and have updates enabled. yum-updatesd should do so as
well, again assuming installing updates is enabled.
I'd assume that PK will do the same if you have enabled auto updates
there.
Also given that you can use --nogpgcheck and/or install key; install
pkg; remove key ... you can't guarantee that there are no
updates-testing pkgs just because there is no key currently.
find-repos-of-install in yum-utils is the much better tool here.
--
James Antill <james(a)fedoraproject.org>
Fedora
5574
days inactive
5577
days old
12 comments
7 participants
participants (7)
-
Casey Dahlin -
Douglas E. Warner -
James Antill -
Jesse Keating -
Panu Matilainen -
Steve Grubb -
Todd Zullinger