Hi, as a follow up to a conversation in #centos-devel, I'd like to get input from the list on this issue.
The question is where to point people, and tools like yum, for the centos gpg key used to verify rpm signatures. My opinion is that pointing to the key in /etc/pki/ which gets installed by the centos- release makes the most sense. This is already installed locally on any centos (-5) machine. See ie. http://bugs.centos.org/view.php?id=2419
From a security standpoint, there are issues with either choice. However, if your install media has been compromised, then there would be many other ways to bypass the gpg checks rather than just changing the gpg key from the centos-release package. Pointing to a URL for the gpg key opens up more security issues such as dns poisoning.
-Jeff
On Monday 25 February 2008, Jeff Sheltren wrote:
Hi, as a follow up to a conversation in #centos-devel, I'd like to get input from the list on this issue.
The question is where to point people, and tools like yum, for the centos gpg key used to verify rpm signatures. My opinion is that pointing to the key in /etc/pki/ which gets installed by the centos- release makes the most sense. This is already installed locally on any centos (-5) machine. See ie. http://bugs.centos.org/view.php?id=2419
I agree with using /etc/pki. The most important thing to change are the gpgkey= lines in our .repo files.
From a security standpoint, there are issues with either choice.
Something like this: current way (www.centos.org) trusts: local machine, dns, centos.org /etc/pki trusts: local machine
/Peter
Jeff Sheltren wrote:
Hi, as a follow up to a conversation in #centos-devel, I'd like to get input from the list on this issue.
The question is where to point people, and tools like yum, for the centos gpg key used to verify rpm signatures. My opinion is that pointing to the key in /etc/pki/ which gets installed by the centos-release makes the most sense. This is already installed locally on any centos (-5) machine. See ie. http://bugs.centos.org/view.php?id=2419
From a security standpoint, there are issues with either choice. However, if your install media has been compromised, then there would be many other ways to bypass the gpg checks rather than just changing the gpg key from the centos-release package. Pointing to a URL for the gpg key opens up more security issues such as dns poisoning.
-Jeff
I think that for the CentOS-Media.repo file that using the /etc/pki directory makes sense.
I STILL think pointing to the http://mirror.centos.org/ site is best for the web enabled CentOS-Base.repo file.
On Feb 25, 2008, at 10:34 AM, Johnny Hughes wrote:
Jeff Sheltren wrote:
Hi, as a follow up to a conversation in #centos-devel, I'd like to get input from the list on this issue. The question is where to point people, and tools like yum, for the centos gpg key used to verify rpm signatures. My opinion is that pointing to the key in /etc/pki/ which gets installed by the centos- release makes the most sense. This is already installed locally on any centos (-5) machine. See ie. http://bugs.centos.org/view.php?id=2419 From a security standpoint, there are issues with either choice. However, if your install media has been compromised, then there would be many other ways to bypass the gpg checks rather than just changing the gpg key from the centos-release package. Pointing to a URL for the gpg key opens up more security issues such as dns poisoning. -Jeff
I think that for the CentOS-Media.repo file that using the /etc/pki directory makes sense.
I STILL think pointing to the http://mirror.centos.org/ site is best for the web enabled CentOS-Base.repo file.
Johnny, could you let us know your reasons for wanting to point to the remote GPG key?
Thanks, Jeff
on 2/25/2008 10:40 AM Jeff Sheltren spake the following:
On Feb 25, 2008, at 10:34 AM, Johnny Hughes wrote:
Jeff Sheltren wrote:
Hi, as a follow up to a conversation in #centos-devel, I'd like to get input from the list on this issue. The question is where to point people, and tools like yum, for the centos gpg key used to verify rpm signatures. My opinion is that pointing to the key in /etc/pki/ which gets installed by the centos-release makes the most sense. This is already installed locally on any centos (-5) machine. See ie. http://bugs.centos.org/view.php?id=2419 From a security standpoint, there are issues with either choice. However, if your install media has been compromised, then there would be many other ways to bypass the gpg checks rather than just changing the gpg key from the centos-release package. Pointing to a URL for the gpg key opens up more security issues such as dns poisoning. -Jeff
I think that for the CentOS-Media.repo file that using the /etc/pki directory makes sense.
I STILL think pointing to the http://mirror.centos.org/ site is best for the web enabled CentOS-Base.repo file.
Johnny, could you let us know your reasons for wanting to point to the remote GPG key?
I would think if you could compromise the mirror dns list, you could have malicious rpm's signed by a malicious key, and have thousands of systems get rooted.
On Monday 25 February 2008, Scott Silva wrote:
on 2/25/2008 10:40 AM Jeff Sheltren spake the following:
On Feb 25, 2008, at 10:34 AM, Johnny Hughes wrote:
...
I STILL think pointing to the http://mirror.centos.org/ site is best for the web enabled CentOS-Base.repo file.
Johnny, could you let us know your reasons for wanting to point to the remote GPG key?
I would think if you could compromise the mirror dns list, you could have malicious rpm's signed by a malicious key, and have thousands of systems get rooted.
I'm not sure what you're saying, but if the above happened. Then my unaffected /etc/pki key would refuse your maliciously signed rpms.
And if my /etc/pki was bad then that was because my install was bad and I'm f**ked anyway.
/Peter
on 2/25/2008 12:50 PM Peter Kjellstrom spake the following:
On Monday 25 February 2008, Scott Silva wrote:
on 2/25/2008 10:40 AM Jeff Sheltren spake the following:
On Feb 25, 2008, at 10:34 AM, Johnny Hughes wrote:
...
I STILL think pointing to the http://mirror.centos.org/ site is best for the web enabled CentOS-Base.repo file.
Johnny, could you let us know your reasons for wanting to point to the remote GPG key?
I would think if you could compromise the mirror dns list, you could have malicious rpm's signed by a malicious key, and have thousands of systems get rooted.
I'm not sure what you're saying, but if the above happened. Then my unaffected /etc/pki key would refuse your maliciously signed rpms.
And if my /etc/pki was bad then that was because my install was bad and I'm f**ked anyway.
/Peter
I was supporting your statement of having local keys. I just replied to the wrong message in the thread. Sorry ;-P
Jeff Sheltren wrote:
On Feb 25, 2008, at 10:34 AM, Johnny Hughes wrote:
Jeff Sheltren wrote:
Hi, as a follow up to a conversation in #centos-devel, I'd like to get input from the list on this issue. The question is where to point people, and tools like yum, for the centos gpg key used to verify rpm signatures. My opinion is that pointing to the key in /etc/pki/ which gets installed by the centos-release makes the most sense. This is already installed locally on any centos (-5) machine. See ie. http://bugs.centos.org/view.php?id=2419 From a security standpoint, there are issues with either choice. However, if your install media has been compromised, then there would be many other ways to bypass the gpg checks rather than just changing the gpg key from the centos-release package. Pointing to a URL for the gpg key opens up more security issues such as dns poisoning. -Jeff
I think that for the CentOS-Media.repo file that using the /etc/pki directory makes sense.
I STILL think pointing to the http://mirror.centos.org/ site is best for the web enabled CentOS-Base.repo file.
Johnny, could you let us know your reasons for wanting to point to the remote GPG key?
We DON'T allow downloads of ISOs from centos.org servers due to bandwidth considerations. It would be fairly easy to put out an ISO that had different RPMS and a different key.
Granted, people CAN check the md5 and sha1 sum of the ISOs if they choose.
Since we do control the content of every mirror.centos.org server, we know that the key file is correct. In order to make that key AND the RPMS be bad, they need a doctored CD *AND* they need to hijack our content by DNS poisoning or getting control of our servers.
I just think if you are using the internet anyway, why not also get the key from a known location.
On Monday 25 February 2008, Johnny Hughes wrote:
Jeff Sheltren wrote:
...
Johnny, could you let us know your reasons for wanting to point to the remote GPG key?
We DON'T allow downloads of ISOs from centos.org servers due to bandwidth considerations. It would be fairly easy to put out an ISO that had different RPMS and a different key.
Granted, people CAN check the md5 and sha1 sum of the ISOs if they choose.
Since we do control the content of every mirror.centos.org server, we know that the key file is correct. In order to make that key AND the RPMS be bad, they need a doctored CD *AND* they need to hijack our content by DNS poisoning or getting control of our servers.
I just think if you are using the internet anyway, why not also get the key from a known location.
I agree that there's something intuitively right about that, but, unfortunately it's wrong :-)
Here's why.
We have to assume that the install the user has is intact and uncompromised. Why? Well, if it has been compromised in any way then not only could it contain a malicious /etc/pki, it could of course have different gpgkey= lines in the .repo files...
It will have to be up to the user to make sure (with our help, signed .isos, installers that check rpm signatures and stage2 signature) that he/she has an ok system. If they fail then they don't really run centos, they run haxx0r os and any attempt to validate anything inside that will fail.
/Peter
2008/2/25 Peter Kjellstrom cap@nsc.liu.se:
On Monday 25 February 2008, Johnny Hughes wrote:
Jeff Sheltren wrote:
...
Johnny, could you let us know your reasons for wanting to point to the remote GPG key?
We DON'T allow downloads of ISOs from centos.org servers due to bandwidth considerations. It would be fairly easy to put out an ISO that had different RPMS and a different key.
Granted, people CAN check the md5 and sha1 sum of the ISOs if they choose.
Since we do control the content of every mirror.centos.org server, we know that the key file is correct. In order to make that key AND the RPMS be bad, they need a doctored CD *AND* they need to hijack our content by DNS poisoning or getting control of our servers.
I just think if you are using the internet anyway, why not also get the key from a known location.
I agree that there's something intuitively right about that, but, unfortunately it's wrong :-)
Here's why.
We have to assume that the install the user has is intact and uncompromised. Why? Well, if it has been compromised in any way then not only could it contain a malicious /etc/pki, it could of course have different gpgkey= lines in the .repo files...
It will have to be up to the user to make sure (with our help, signed .isos, installers that check rpm signatures and stage2 signature) that he/she has an ok system. If they fail then they don't really run centos, they run haxx0r os and any attempt to validate anything inside that will fail.
/Peter
This discussion has been dormant for a while... With 5.2 just around the corner, isn't it a good idea to wrap this up and reach some sort of a conclusion?
Akemi
On Saturday 10 May 2008, Akemi Yagi wrote:
2008/2/25 Peter Kjellstrom cap@nsc.liu.se:
On Monday 25 February 2008, Johnny Hughes wrote:
Jeff Sheltren wrote:
...
Johnny, could you let us know your reasons for wanting to point to the remote GPG key?
We DON'T allow downloads of ISOs from centos.org servers due to bandwidth considerations. It would be fairly easy to put out an ISO that had different RPMS and a different key.
Granted, people CAN check the md5 and sha1 sum of the ISOs if they choose.
Since we do control the content of every mirror.centos.org server, we know that the key file is correct. In order to make that key AND the RPMS be bad, they need a doctored CD *AND* they need to hijack our content by DNS poisoning or getting control of our servers.
I just think if you are using the internet anyway, why not also get the key from a known location.
I agree that there's something intuitively right about that, but, unfortunately it's wrong :-)
Here's why.
We have to assume that the install the user has is intact and uncompromised. Why? Well, if it has been compromised in any way then not only could it contain a malicious /etc/pki, it could of course have different gpgkey= lines in the .repo files...
It will have to be up to the user to make sure (with our help, signed .isos, installers that check rpm signatures and stage2 signature) that he/she has an ok system. If they fail then they don't really run centos, they run haxx0r os and any attempt to validate anything inside that will fail.
/Peter
This discussion has been dormant for a while... With 5.2 just around the corner, isn't it a good idea to wrap this up and reach some sort of a conclusion?
Akemi
I would have liked to wake this thread in time for 5.2 but unfortunately I havn't had any time for centos lately. :-(
It was my interpretation that the discussion ended somewhat in favour of /etc/pki but either that was just my wishful thinking or it got forgotten/delayed/droped because it didn't make it into centos-release for 5.2.
What are the concerns people still have regarding this? (switching gpgkey= from http://centos.org... to /etc/pki/...)
/Peter
2008/2/25 Peter Kjellstrom cap@nsc.liu.se:
We have to assume that the install the user has is intact and uncompromised. Why? Well, if it has been compromised in any way then not only could it contain a malicious /etc/pki, it could of course have different gpgkey= lines in the .repo files...
Or a modified yum or RPM that only appears to do verification. I agree that we should at the very least suppose that the user verifies the installation media.
As for DNS poisoning or hacking, that misery can potentially happen to everyone, and a good manner to guard against this is relying on the pre-installed key from media that was proven to be correct. So, I think this should be the default behavior.
Take care, Daniel
-
Akemi Yagi -
Daniel de Kok -
Jeff Sheltren -
Johnny Hughes -
Peter Kjellstrom -
Scott Silva