Dear List, I have spent some time playing around with oscap and the RHEL OVAL feed (https://www.redhat.com/security/data/oval/v2/RHEL8/, also check Chapter 16 of the RHEL 8 Design Guide). Because I could not find an existing OVAL file for CentOS, I downloaded one of the RHEL8 files and managed to modify (eg. the rhel-8.1-e4s.oval.xml) it to make it work on a CentOS machine. Basically I just had to change the package signing key check to use the CentOS key and I had to replace the redhat-release RPM package name with "centos-release". Obviously, this would violate all kinds of rights if redistributed, due to the fact that the upstream vendor is named all over the place, but technically it "worked". On an internal system running a freshly updated CentOS 8.1 system I ended up with three errors, titled: * RHSA-2019:4269: container-tools:rhel8 security and bug fix update (Important) * RHSA-2019:3403: container-tools:rhel8 security, bug fix, and enhancement update (Important) * RHSA-2019:2799: nginx:1.14 security update (Important) This raises some questions (some of them connected), namely: Q1) There are no equivalent CESA advisories for those RHSA advisories: why is that? Note that there are also no equivalent CentOS packages to those mentioned in the RHSA advisories. (My guess: because, when the advisories where issued, Centos already had moved on to 8.2) Q2) Does this indicate a problem in the release process / handling of upstream updates on the side of the CentOS project? Were the advisories missed at the time of issuance? Q3) Does this indicate that only the latest CentOS (minor) release can be considered "secure" or "patched"? Q4) Is there a native OVAL file released from the CentOS project covering these issues? It could be extremely similar to the RHEL one, but it should take the answers to the above questions into account (eg. it could require the latests minor-release and there would only be one file for CentOS 8 if the answer to Q3 is "yes"). Q5) If the answer to the last question is "no": shouldn't there be such a resource? Thanks for any answers. peter
On Tue, Aug 4, 2020 at 11:34 AM <centos at niob.at> wrote:> Q5) If the answer to the last question is "no": shouldn't there be such > a resource? >CentOS doesn't publish security errata. If you need it then you should either buy RHEL, or deal with putting together your own set up with something like http://cefs.steve-meier.de/
On 04/08/2020 23:50, Jon Pruente wrote:> On Tue, Aug 4, 2020 at 11:34 AM <centos at niob.at> wrote: > >> Q5) If the answer to the last question is "no": shouldn't there be such >> a resource? >> > CentOS doesn't publish security errata. If you need it then you should > either buy RHEL, or deal with putting together your own set up with > something like http://cefs.steve-meier.de/I expected just this answer, and we do have a RHEL subscription (and BTW: thanks for the link). But you missed the main point by omitting the other questions (especially Q1, Q2 and Q3): There are upstream package versions that were never rebuilt for CentOS. For instance: If, for whatever reason, I am required to stay with nginx 1.14.1 then the missing rebuild of the packages mentioned in RHSA-2019:2799 (https://access.redhat.com/errata/RHSA-2019:2799) would leave me with a vulnerable system. The question for an OVAL feed is actually an add-on question: In the same spirit that is the base for the CentOS project itself: wouldn't such a feed be a good thing to have? Otherwise your answer could be the catch-all answer to all questions CentOS: Go get a commercial subscription. Personally, I think such an answer is not very helpful. So what do you think about the underlying issue? Under what argumentation does it NOT constitute to be an issue? peter
> Q3) Does this indicate that only the latest CentOS (minor) release can > be considered "secure" or "patched"?Yes. Security errata for previous Enterprise Linux minor releases are a Red Hat product called Extended Update Support (EUS) [0]. CentOS doesn't build EUS updates. CentOS point releases are a point in time reference and an implementation detail, not something you should try to lock your system to. When someone says they are using CentOS X.Y, that just means that they haven't updated their system since X.Y+1 was released. Effectively, you don't have CentOS 8.1, you have outdated CentOS 8. [0] https://access.redhat.com/articles/rhel-eus On Tue, Aug 4, 2020 at 11:34 AM <centos at niob.at> wrote:> > Dear List, > > I have spent some time playing around with oscap and the RHEL OVAL feed > (https://www.redhat.com/security/data/oval/v2/RHEL8/, also check Chapter > 16 of the RHEL 8 Design Guide). Because I could not find an existing > OVAL file for CentOS, I downloaded one of the RHEL8 files and managed to > modify (eg. the rhel-8.1-e4s.oval.xml) it to make it work on a CentOS > machine. Basically I just had to change the package signing key check to > use the CentOS key and I had to replace the redhat-release RPM package > name with "centos-release". Obviously, this would violate all kinds of > rights if redistributed, due to the fact that the upstream vendor is > named all over the place, but technically it "worked". > > On an internal system running a freshly updated CentOS 8.1 system I > ended up with three errors, titled: > > * RHSA-2019:4269: container-tools:rhel8 security and bug fix update > (Important) > > * RHSA-2019:3403: container-tools:rhel8 security, bug fix, and > enhancement update (Important) > > * RHSA-2019:2799: nginx:1.14 security update (Important) > > This raises some questions (some of them connected), namely: > > Q1) There are no equivalent CESA advisories for those RHSA advisories: > why is that? Note that there are also no equivalent CentOS packages to > those mentioned in the RHSA advisories. (My guess: because, when the > advisories where issued, Centos already had moved on to 8.2) > > Q2) Does this indicate a problem in the release process / handling of > upstream updates on the side of the CentOS project? Were the advisories > missed at the time of issuance? > > Q3) Does this indicate that only the latest CentOS (minor) release can > be considered "secure" or "patched"? > > Q4) Is there a native OVAL file released from the CentOS project > covering these issues? It could be extremely similar to the RHEL one, > but it should take the answers to the above questions into account (eg. > it could require the latests minor-release and there would only be one > file for CentOS 8 if the answer to Q3 is "yes"). > > Q5) If the answer to the last question is "no": shouldn't there be such > a resource? > > Thanks for any answers. > > peter > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- Carl George