This command output is odd:
yum update --security ... No packages needed for security; 118 packages available
However, this command says there's an OpenSSL update:
yum update openssl ... ---> Package openssl-libs.x86_64 1:1.0.1e-51.el7_2.2 will be updated ---> Package openssl-libs.x86_64 1:1.0.1e-51.el7_2.4 will be an update
Why does yum not consider this CESA a security update?
Perplexed, ak.
On 02/03/16 15:57, Anthony K wrote:
This command output is odd:
yum update --security ... No packages needed for security; 118 packages available
...
Why does yum not consider this CESA a security update?
Cherry-picking updates is not supported by CentOS, this is because each package is built on a system with all previous updates applied and as such each update that you install should have all previous updates applied or there can be problems.
As such CentOS does not support the --security option for yum, nor does it support the yum-security plugin. You are expected to update your entire system, not to do so will leave you with an unsupported system. Also there will be other packages as well that have security issues that need updating.
Peter
On 03/01/2016 09:17 PM, Peter wrote:
On 02/03/16 15:57, Anthony K wrote:
This command output is odd:
yum update --security ... No packages needed for security; 118 packages available
...
Why does yum not consider this CESA a security update?
Cherry-picking updates is not supported by CentOS, this is because each package is built on a system with all previous updates applied and as such each update that you install should have all previous updates applied or there can be problems.
As such CentOS does not support the --security option for yum, nor does it support the yum-security plugin. You are expected to update your entire system, not to do so will leave you with an unsupported system. Also there will be other packages as well that have security issues that need updating.
RHEL does not support only security updates either .. they do have things like AUS / EAS .. but those things require all updates to be installed, not just all security updates.
If you look at this update:
https://access.redhat.com/errata/RHSA-2016:0303
Look in the *Solution* section:
"Before applying this update, make sure all previously released errata relevant to your system have been applied."
That does not say all security errata .. it says all errata. The same thing is on every Red Hat errata page. They expect that you are running whatever is an updated system. If you are running AUS or EUS, they still expect you to do all updates for that repo, not just security updates.
BUt the security plugins do not work for CentOS and they never have, Peter is correct, you need to run yum update or call out the specific packages you want updated.
You can look at the announce list to figure out which ones are SA or BA or EA .. but you want all of them, as they go together.
On 03/01/2016 09:41 PM, Johnny Hughes wrote:
On 03/01/2016 09:17 PM, Peter wrote:
On 02/03/16 15:57, Anthony K wrote:
This command output is odd:
yum update --security ... No packages needed for security; 118 packages available
...
Why does yum not consider this CESA a security update?
Cherry-picking updates is not supported by CentOS, this is because each package is built on a system with all previous updates applied and as such each update that you install should have all previous updates applied or there can be problems.
As such CentOS does not support the --security option for yum, nor does it support the yum-security plugin. You are expected to update your entire system, not to do so will leave you with an unsupported system. Also there will be other packages as well that have security issues that need updating.
RHEL does not support only security updates either .. they do have things like AUS / EAS .. but those things require all updates to be installed, not just all security updates.
If you look at this update:
https://access.redhat.com/errata/RHSA-2016:0303
Look in the *Solution* section:
"Before applying this update, make sure all previously released errata relevant to your system have been applied."
That does not say all security errata .. it says all errata. The same thing is on every Red Hat errata page. They expect that you are running whatever is an updated system. If you are running AUS or EUS, they still expect you to do all updates for that repo, not just security updates.
BUt the security plugins do not work for CentOS and they never have, Peter is correct, you need to run yum update or call out the specific packages you want updated.
You can look at the announce list to figure out which ones are SA or BA or EA .. but you want all of them, as they go together.
Also, just installing the update is not enough, you also need to make sure SSLv2 is disabled on the appropriate services:
On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote:
On 03/01/2016 09:41 PM, Johnny Hughes wrote:
BUt the security plugins do not work for CentOS and they never have, Peter is correct, you need to run yum update or call out the specific packages you want updated.
I totally understand the necessity of a full system update. However, this begs the question "Why code an option into yum that is of no use?" Was there a time when this option was functional? If yes, what caused its removal? Was it a system compromise at some big corporation and someone got sued/fired? What? Don't spare any gory details either!
ak.
On 2 March 2016 at 11:24, Anthony K akcentos@anroet.com wrote:
On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote:
On 03/01/2016 09:41 PM, Johnny Hughes wrote:
BUt the security plugins do not work for CentOS and they never have, Peter is correct, you need to run yum update or call out the specific packages you want updated.
I totally understand the necessity of a full system update. However, this begs the question "Why code an option into yum that is of no use?" Was there a time when this option was functional? If yes, what caused its removal? Was it a system compromise at some big corporation and someone got sued/fired? What? Don't spare any gory details either!
Specifically it requires errata data within the repo metadata.
It exists in yum since CentOS is a RHEL rebuild and upstream provides that errata data for RHEL users.
If you set up something like Spacewalk then you can use something like CEFS to import that errata data to make --security work for centos systems.
Potentially you could use a combination of his work, a bit of scripting and createrepo to provide your own errata data.
*That all being said* apply all errata still applies whenever issues arise ;)
On 03/02/2016 03:24 AM, Anthony K wrote:
On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote:
On 03/01/2016 09:41 PM, Johnny Hughes wrote:
BUt the security plugins do not work for CentOS and they never have, Peter is correct, you need to run yum update or call out the specific packages you want updated.
I totally understand the necessity of a full system update. However, this begs the question "Why code an option into yum that is of no use?" Was there a time when this option was functional? If yes, what caused its removal? Was it a system compromise at some big corporation and someone got sued/fired? What? Don't spare any gory details either!
yum does not need to be restricted to vendor repositories.
You can add package repositories maintained by anyone, and some of them may choose to distinguish between security and non-security updates, so it is appropriate for yum as packaged in CentOS to retain that feature even if the CentOS repositories themselves do not make use of it.
Personally I think it is a dumb option and is in contrast to KISS.
KISS says keep your system up to date. RHEL/CentOS works really hard to prevent updates from breaking a system. That's why many of us use it.
So it doesn't make sense to not update when an update is available, making security specific updates kind of worthless.
On 03/02/2016 05:24 AM, Anthony K wrote:
On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote:
On 03/01/2016 09:41 PM, Johnny Hughes wrote:
BUt the security plugins do not work for CentOS and they never have, Peter is correct, you need to run yum update or call out the specific packages you want updated.
I totally understand the necessity of a full system update. However, this begs the question "Why code an option into yum that is of no use?" Was there a time when this option was functional? If yes, what caused its removal? Was it a system compromise at some big corporation and someone got sued/fired? What? Don't spare any gory details either!
ak.
It would require 2 things that we currently don't do.
1. Host all the RPMs every built in one place that every update can hit.
2. An errata.xml file that contains information that is NOT open source and not allowed to be gathered by CentOS. (Although James Hogarth provided a link to one elsewhere in this thread)
First for #1:
We utilize several hundred servers and free bandwidth that they provide that are donated to the CentOS Project to distribute updates. This 'donated network' makes up the DNS names mirror.centos.org, msync.centos.org, and cloud.centos.org, etc. We use this network to distribute CentOS Linux to more than 630 servers (external mirrors) in 85 countries all over the world.
We could not provide CentOS for free for the last 13 years if we did not have both the hundreds of donated machines that make up mirror.centos.org (and msync.centos.org) OR those external mirrors.
The vast majority of our donated mirror network servers do not have room to host all the RPMs from all active centos versions in one place and to distribute them to the vast external server network.
We can't afford to replace the hundreds of donated (free) servers with ones that CAN host that amount of data AND also pay for enough bandwidth to distribute it to the external mirrors. Even if we could, not all the current 635 mirrors would be able to take all that data.
This is one of many reasons why there is a subscription price for RHEL.
Even if we DID all of that. Other than returning a cou0ple of updates with the yum security plugin command, you STILL need to run 'yum update' to get all the updates as JUST doing the security ones is not supported / does not necessarily fix the security issues.
Then there is #2:
The information that goes INTO the XML file we would need to generate does not come from the source code from Red Hat Enterprise Linux that we use to build CentOS Linux. It would only from screen scraping places like:
https://rhn.redhat.com/errata/rhel-server-7-errata.html
BUT, if you go to the 'terms of use' for Red Hat portals .. here:
https://access.redhat.com/help/terms/
You will see the definition of "Red Hat Content". While we CAN distribute the software we build (it is open source) .. we *CAN NOT* scrape and/or Distribute content that is *NOT* open source but us copyrighted intellectual property.
To the best of our knowledge, the information needed to make up all the information needed to create the Errata XML file requires to make the yum security plugin work is not available in a complete open source way where we would be able to be distributed.
That is *WHY* the CentOS team does not copy and distribute any content into our announcements, but only links to open content in our announcements.
So, we can not distribute the information that is required in the XML file that would make the yum security plugin work .. *BUT* even if we could, you *STILL* need to run 'yum update' to get all the updates as JUST doing the security ones is not supported / does not necessarily fix the security issues.
Hopefully this makes sense.
You can instead just look at this:
https://lists.centos.org/pipermail/centos-announce/
(or subscribe to the CentOS announce mailing list to get emails)
Both of those places will tell you when there is a security update.
OR, you can subscribe to RHEL and use the information in the yum security plugin.
On Wed, 2016-03-02 at 07:33 -0600, Johnny Hughes wrote:
Hopefully this makes sense.
You can instead just look at this:
https://lists.centos.org/pipermail/centos-announce/
(or subscribe to the CentOS announce mailing list to get emails)
Both of those places will tell you when there is a security update.
OR, you can subscribe to RHEL and use the information in the yum security plugin.
Thanks for not sparing the gory details (and Alice and James) - much appreciated!
I normally test my updates on non-critical systems before deploying to production. However, in this instance, I had been away from the office and wanted to quickly patch the openssl vulnerability before other non -critical/security related.
In the end, I bit the bullet and just upgraded everything and no harm done.
ak.
On Wed, March 2, 2016 5:24 am, Anthony K wrote:
On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote:
On 03/01/2016 09:41 PM, Johnny Hughes wrote:
BUt the security plugins do not work for CentOS and they never have, Peter is correct, you need to run yum update or call out the specific packages you want updated.
I totally understand the necessity of a full system update. However, this begs the question "Why code an option into yum that is of no use?"
We are talking here CentOS and RHEL Linux. yum is an abbreviation of: "Yellowdog Update Manager". It was originally created by YellowDog Linux project for their Linux distribution. I don't know is they (YellowDog) actually using this particular feature or not, but RedHat (and hence CentOS) use features of yum they think fitting in their model. Incidentally, sometimes even when the project uses his own creature itself, they may end up abandoning some of the features that were originally coded in. Everyone who ever architectured some project himself, know that that often happens.
Valeri
Was there a time when this option was functional? If yes, what caused its removal? Was it a system compromise at some big corporation and someone got sued/fired? What? Don't spare any gory details either!
ak.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
One more voice on this: we actually run the yum security plugin, several times a week, and it does report things... and almost all our systems are CentOS.
When I see something in there, just as when I see an announcement where there are updates marked important, and esp. critical, we roll them out, by themselves if possible, within days, as opposed to waiting until the maintenance window, which could be 3.5 weeks away.
We only do the full updates during the maintenance window (or via negotiation with a workstation owner....)
mark
Once upon a time, Valeri Galtsev galtsev@kicp.uchicago.edu said:
We are talking here CentOS and RHEL Linux. yum is an abbreviation of: "Yellowdog Update Manager". It was originally created by YellowDog Linux project for their Linux distribution.
Actually, yum is Yellowdog Updater, Modified. Seth Vidal (RIP) and others at Duke rewrote YUP (the Yellowdog UPdater) to handle Red Hat Linux.
On Wed, March 2, 2016 9:57 am, Chris Adams wrote:
Once upon a time, Valeri Galtsev galtsev@kicp.uchicago.edu said:
We are talking here CentOS and RHEL Linux. yum is an abbreviation of: "Yellowdog Update Manager". It was originally created by YellowDog Linux project for their Linux distribution.
Actually, yum is Yellowdog Updater, Modified. Seth Vidal (RIP) and others at Duke rewrote YUP (the Yellowdog UPdater) to handle Red Hat Linux.
Thanks, Chris! My memory ain't that good anymore...
valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
I understand that some people might be trying to cherry-pick their updates and the assertion that doing so is not supported. But that is not the only way in which --security can be used and it is a bit boring to continually see whining about the assumptive use.
For me it is about scheduling -- it would answer the question: Does this system need updating immediately, vs scheduled for / deferred until a convenient time.
I wish --security was functional and I do not accept that because it can be abused that it should therefore never be. That CentOS as yet has no way to make it functional is sad, and I hope that the lack is not due to the assumed use resulting in it being ignored.
/mark
On 03/02/2016 10:42 AM, Mark Milhollan wrote:
I understand that some people might be trying to cherry-pick their updates and the assertion that doing so is not supported. But that is not the only way in which --security can be used and it is a bit boring to continually see whining about the assumptive use.
For me it is about scheduling -- it would answer the question: Does this system need updating immediately, vs scheduled for / deferred until a convenient time.
I wish --security was functional and I do not accept that because it can be abused that it should therefore never be. That CentOS as yet has no way to make it functional is sad, and I hope that the lack is not due to the assumed use resulting in it being ignored.
That is not the reason, I have posted the reason several times .. including in this thread.
We do not have enough space on donated mirrors and the data required for the xml file is not redistributable.
It is not being ignored, it was designed to be used within rhn and since we give CentOS away for free, we can't buy the machines or bandwidth we need to include all rpms in all trees. Even if we could do that, we can't steal information and redistribute it if it is not licensed for such distribution.
On Wed, 2 Mar 2016, Johnny Hughes wrote:
On 03/02/2016 10:42 AM, Mark Milhollan wrote:
I wish --security was functional
I hope that the lack is not due to the assumed use resulting in it being ignored.
That is not the reason,
We do not have enough space on donated mirrors
Surely the data could be tailored to provide only that which applies to the current set of RPMs. Do we know that yum will fail if RPMs are cited in the file but which are not available for install?
the data required for the xml file is not redistributable.
That does sound like it is being ignored, because you know you can't do it.
As things stand.
(I think you should put all this in an/the FAQ then point people to it, instead of sending large swaths of the same words yet again, which must surely be frustrating.)
But the project could lobby Red Hat for access to the file, whether for just CentOS (RH has done things just for CentOS before) or for the wider community of rebuilders. I can't know if this has been attempted, but it has not been mentioned as having been asked.
Can I help lobby for such access? I bet that would only be possible after CentOS has started such a petition, since non-RHEL users cannot submit feature requests. But the CentOS project isn't quite in the same boat as its users, so you might be able to open such a ticket and if it were public others could jump in with their support. Or would a SIG be the right avenue?
Would Red Hat pay any attention to 3rd party lobbying sites? At least I think I remember such existing, though I cannot at the moment recall any names.
/mark
On 03/03/2016 02:58 PM, Mark Milhollan wrote:
On Wed, 2 Mar 2016, Johnny Hughes wrote:
On 03/02/2016 10:42 AM, Mark Milhollan wrote:
I wish --security was functional
I hope that the lack is not due to the assumed use resulting in it being ignored.
That is not the reason,
We do not have enough space on donated mirrors
Surely the data could be tailored to provide only that which applies to the current set of RPMs. Do we know that yum will fail if RPMs are cited in the file but which are not available for install?
Whose current set .. your's or the guy that hasn't done an update since 2007?
Te problem is, if we say we support the security plugin, then it has to be able to update ANY configuration and all security updates.
Let's say that you are on 6.4 right now, there is a security update in 6.5 and 6.6, and there is a bugfix update in 6.7 (current version), you run the security plugin and it says .. no security updates (because the 6.7 update is only a bugfix).
You are instead behind and have a security problem .. no, you have to have all or it doesn't work, and it then causes people to think they are OKwhen they are not.
the data required for the xml file is not redistributable.
That does sound like it is being ignored, because you know you can't do it.
As things stand.
(I think you should put all this in an/the FAQ then point people to it, instead of sending large swaths of the same words yet again, which must surely be frustrating.)
But the project could lobby Red Hat for access to the file, whether for just CentOS (RH has done things just for CentOS before) or for the wider community of rebuilders. I can't know if this has been attempted, but it has not been mentioned as having been asked.
One of the things RHEL does that CentOS doesn't do (and has never done) is verify security issues, verify fixes correct those issues and provide assurance that they are fixed. They is why RHEL is a paid product and CentOS is free.
<snip>
Hey all,
Sorry to jump in here but out of curiosity, has the patch actually been back ported to earlier versions of OpenSSL regarding the recent DROWN attack? I've checked the RPM change log and nothing's been mentioned relating to CVE-2016-0800 (I think that was the CVE number). Or is this thread not relating to that vulnerability?
Kind regards
James Washington
On 7 Mar 2016, at 16:34, Johnny Hughes johnny@centos.org wrote:
On 03/03/2016 02:58 PM, Mark Milhollan wrote:
On Wed, 2 Mar 2016, Johnny Hughes wrote: On 03/02/2016 10:42 AM, Mark Milhollan wrote:
I wish --security was functional
I hope that the lack is not due to the assumed use resulting in it being ignored.
That is not the reason,
We do not have enough space on donated mirrors
Surely the data could be tailored to provide only that which applies to the current set of RPMs. Do we know that yum will fail if RPMs are cited in the file but which are not available for install?
Whose current set .. your's or the guy that hasn't done an update since 2007?
Te problem is, if we say we support the security plugin, then it has to be able to update ANY configuration and all security updates.
Let's say that you are on 6.4 right now, there is a security update in 6.5 and 6.6, and there is a bugfix update in 6.7 (current version), you run the security plugin and it says .. no security updates (because the 6.7 update is only a bugfix).
You are instead behind and have a security problem .. no, you have to have all or it doesn't work, and it then causes people to think they are OKwhen they are not.
the data required for the xml file is not redistributable.
That does sound like it is being ignored, because you know you can't do it.
As things stand.
(I think you should put all this in an/the FAQ then point people to it, instead of sending large swaths of the same words yet again, which must surely be frustrating.)
But the project could lobby Red Hat for access to the file, whether for just CentOS (RH has done things just for CentOS before) or for the wider community of rebuilders. I can't know if this has been attempted, but it has not been mentioned as having been asked.
One of the things RHEL does that CentOS doesn't do (and has never done) is verify security issues, verify fixes correct those issues and provide assurance that they are fixed. They is why RHEL is a paid product and CentOS is free.
<snip>
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 03/07/2016 10:14 AM, James Washington wrote:
Hey all,
Sorry to jump in here but out of curiosity, has the patch actually been back ported to earlier versions of OpenSSL regarding the recent DROWN attack? I've checked the RPM change log and nothing's been mentioned relating to CVE-2016-0800 (I think that was the CVE number). Or is this thread not relating to that vulnerability?
Kind regards
James Washington
Drown depends upon SSLv2
I'm not sure if this removed SSLv2 or not but I am not personally aware of any public services that enabled SSLv2 by default in CentOS 7 anyway, so unless you have a service supporting SSLv2 you are not vulnerable to DROWN.
Reality is, you should not have either SSLv2 or SSLv3 enabled on any service and disabling was best practice long before DROWN.
On 03/07/2016 12:14 PM, James Washington wrote:
Hey all,
Sorry to jump in here but out of curiosity, has the patch actually been back ported to earlier versions of OpenSSL regarding the recent DROWN attack? I've checked the RPM change log and nothing's been mentioned relating to CVE-2016-0800 (I think that was the CVE number). Or is this thread not relating to that vulnerability?
Kind regards
Yes, this update addresses Drown .. but installing the update alone is not enough, you also have to turn off SSLv2
You can see how to do that for many different services here:
https://access.redhat.com/articles/1462183
And lots of info here:
Am 02.03.2016 um 17:42 schrieb Mark Milhollan mlm@pixelgate.net:
I understand that some people might be trying to cherry-pick their updates and the assertion that doing so is not supported. But that is not the only way in which --security can be used and it is a bit boring to continually see whining about the assumptive use.
For me it is about scheduling -- it would answer the question: Does this system need updating immediately, vs scheduled for / deferred until a convenient time.
I wish --security was functional and I do not accept that because it can be abused that it should therefore never be. That CentOS as yet has no way to make it functional is sad, and I hope that the lack is not due to the assumed use resulting in it being ignored.
As it was said, "yum check-update/update" is the way to go (also for RHEL).
We do not need here something like SCAP, therefore
http://search.gmane.org/?query=CESA&group=gmane.linux.centos.announce&am...
gives enough informations to schedule the security activities.
-- LF
-
Alice Wonder -
Anthony K -
Chris Adams -
James Hogarth -
James Washington -
Johnny Hughes -
Leon Fauster -
m.roth＠5-cent.us -
Mark Milhollan -
Peter -
Valeri Galtsev