Consuming OVAL security content and Integrate with Uyuni

[admd]

Project Title:
Consuming OVAL security content

Description:
OVAL® is an XML description and reporting format used to assess and report the state of an operating system. More in-depth information about OVAL can be found on the Mitre OVAL website.

SUSE is currently providing OVAL information for SUSE Linux Enterprise products that allow to assess and report on the RPM package versions affected by known security issues in a CVE to RPM name/version mapping.

The SUSE-provided OVAL data includes:

• The patch-style OVAL data expresses all security updates on a patch level, these can include multiple CVEs per patch.

  • This data includes both released updates and updates currently in QA, with the latter being marked as such.

• The vulnerability OVAL data expresses security vulnerabilities on a CVE level.

  • The data contains already released package versions for the CVE, and also the CVEs planned to be released and the CVEs that do not affect the respective packages.

The OVAL data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).
This information is currently published per major product line for all processor architectures in one XML file:

Ref: https://www.suse.com/de-de/support/security/oval/

---

All the files are available here https://ftp.suse.com/pub/projects/security/oval/

In general, each major version of SUSE has 3 oval files in the following format

- suse.linux.enterprise.server.[version]-[affected|patch].xml

In case of SLE 15, we have the following,

1. suse.linux.enterprise.server.15-affected.xml - This is CVE indexed, and contains released, not affected and affected info

2. suse.linux.enterprise.server.15.xml - It has the CVE based info, but it contains the released updates and the "not affected" ones

3. suse.linux.enterprise.server.15-patch.xml - Patch variant of the 2nd file

---

Deliverable:

1. The first task is to read and parse the files available here https://ftp.suse.com/pub/projects/security/oval/ based on the product and store them in a database that one can query based on entered criteria.

Usual queries

• Enter the CVE number and check which products are affected
• Check if the fix of a particular CVE is already released or is currently at QA
• Check if the product is affected at all against the CVE
  There is some more useful info that we can display like CVSS score, take this page as inspiration to see what else we can show https://www.suse.com/security/cve/CVE-2022-0492.html

2. The second task is to integrate this with Uyuni.
   Uyuni is an open-source systems management solution that can manage various Linux distributions using a powerful web UI and API. One of the core features of Uyuni is the CVE audit. Currently, it looks at the channel files to convey information to figure out the information about the CVEs and present it to the user. It mostly works but it could be further improved by consuming the oval content from the 1st part.

For example, currently, Uyuni cannot distinguish between

• Affected, but patch not (yet) available and
• Not affected

This could be fixed with the oval files consumption.

Mentor: @admd @parlt91

Skills:

• Good knowledge of the Java programming language and databases
• Some knowledge with Oval files will go a long way

Skill Level:
The first part should be Medium but the second part could be tricky because it involves a huge code base which means the overall skill level here is Medium / Hard.

Prject Size: Large Sized Project (350 hours)

Get started:

• Get familiar with the Oval file format
• Learn different types of Oval files(e.g suse.linux.enterprise.server.15-affected.xml, suse.linux.enterprise.server.15-patch.xml & suse.linux.enterprise.server.15.xml) that SUSE provides and see how they are different from each other.
• Get any language(recommended language is java as it would help with the second part) of your choice to parse these files and store them in a database(recommended database is PostgreSQL as it would help with the second part) of your choice to query the useful info
• Set up a development environment for Uyuni locally using sumaform

[dhananjay8968]

Hello, I have experience of working with C++ , Python and Ruby. In databases I have worked with MySQL. This project sounds interesting to me. I would like to contribute to this project this summer.

[admd]

Hi @dhananjay8968 , thank you for your interest. You are quite well equipped for the 1st part but for the second one, you will need to have some java knowledge.

[dhananjay8968]

Hi, Sure I would be learning Java and going through the get started and learn more about oval format. Are there any good first issues related to this so that I can try solving them?

[admd]

I'm glad to hear that. We have some easy issues, and you can choose any one of them to tackle.
https://github.com/uyuni-project/uyuni/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+label%3Ajava

To setup the development env, these links could be helpful https://github.com/uyuni-project/uyuni/wiki/Java-Development-Environment and https://github.com/uyuni-project/uyuni/wiki/Uyuni-development-in-no-time

[HoussemNasri]

Hi @admd,

I wanted to get your opinion on a topic related to OVAL. As you know, OVAL allows for extending the core XML schema and defining system-specific elements, such as rpminfo_state for Linux.

My question is, is it required of the project to support all of the available system extensions or only the ones specified by Linux? Or can we choose which system extensions we should support?

Thank you for your time and assistance.

Regards,

[admd]

Hey @HoussemNasri , in context of this project we are only interested in the ones specific to Linux.

Having said that, this particular project is mainly about consuming these oval files but all of these oval files will be related to linux distros, mainly rpm and dpkg based.

[affan00733]

Hi ,
I am a working professional and willing to participate in GSOC 2023 so want to solve this issue

[HoussemNasri]

Hi @admd,

Thank you for answering my previous question! It cleared a lot of doubts in my mind.

Since then, I've made more progress on the proposal and wanted to add an alternative solutions section. So, I have been considering alternative approaches to the suggested parse-data-and-store-it-in-Postgresql solution. After doing some research, I came up with three possible alternatives:

1. Use a native XML database
   With this approach, we can just feed the XML files to an XML database such as ExistDB and query the database using XQuery. I experimented with ExistDB a little bit, and it appears to do the job. Performance is excellent, setup is simple, the tooling is not top-notch but it works, there is documentation, and the last pushed commit was two days ago. The embedded version takes around 80MB of disk space, and the standalone takes 160MB. I'm not familiar with Uyuni usage, so I can't say whether that's good or bad. ExistDB has REST and XML-RPC APIs, so it doesn't need to be installed on the same machine as Uyuni.
2. Convert XML to JSON and use a JSON document database .e.g. MongoDB
   This solution is similar to the previous one, the only difference is that we'll be using JSON instead of XML. When I was searching for native XML databases, most of the databases I found were dead. JSON seems to have taken over the document database arena. I don't know how much ExistDB is gonna live so I thought this option is worth considering.
3. Perform XPath queries in-memory using a DOM-based XML parser
   The biggest downside of using a DOM-based XML parser is that the whole XML file would need to be loaded into memory. However, since the OVAL files for SUSE take up a maximum of 250 MB of space, and the parser would run on the server, the space requirements are negligible. The performance of the XPath queries might not be as fast as a native XML database, but in my opinion, they are acceptable for the project's use case. Assuming that we are not going to perform any data manipulation on the OVAL files, this solution seems sufficient.

What are your thoughts on the matter? Do you think these solutions would work better than the Postgresql solution?

I look forward to hearing your feedback.

Thanks

[admd]

Hi @HoussemNasri ,

Thank you for submitting your proposals. They all appear to be interesting, but there are certain limitations that we need to consider.

Firstly, we prefer not to add any new dependencies, such as a new database, other than the one we already have. Hence, we have to stick to Postgres, although it could be a different schema or even a different Postgres database instance.

Secondly, for our specific use case, we do not require every piece of information that is available in these files. Instead, we only need a subset of the data.

Therefore, it would be better to store the only relevant information in the Postgres database rather than querying the XML files in memory or introducing a new database.

[HoussemNasri]

this particular project is mainly about consuming these oval files but all of these oval files will be related to linux distros, mainly rpm and dpkg based.

@admd I see that Ubuntu is in the list of supported clients in Uyuni but I can't think of any way to determine if an Ubuntu machine is affected by consuming these oval files. Maybe by reading Ubuntu's channel information?

[admd]

Indeed. Uyuni handles Ubuntu differently and get errata information from https://usn.ubuntu.com/usn-db/database.json file and then based on that information decides if some product is affected or not.

[HoussemNasri]

I see – through UbuntuErrataManager, but how about other distributions, Oracle, Rocky, or Debian? Can consuming oval files help there to identify affected systems or channels are gonna be used? It's easy to identify affected versions of OpenSUSE products by looking at the <affected> XML element in the provided oval files. However, for the other distributions, it's more involved: one way to do it is by fetching the list of installed packages on a certain distribution/version from the proper channel and then traversing each CVE <criteria> element in the oval files to check if it is affected.

Also, the provided oval files use rpm_test to test for rpm packages, but how about systems that use dpkg? In other words what if one package exists in dpkg but not in rpm?

Furthermore, I began looking around in the codebase; I would appreciate it if you could point me to important classes or documents that I should check.

Thanks!

[admd]

Hi @HoussemNasri
Currently, CVE audit is not available for Debian. Ubuntu is handled differently as mentioned above and for all other products in Uyuni, we use channel metadata for this information and then use that info to decide if a product is affected or not. But this approach has some imitations as for example, we can't differentiate between

• Affected, but patch not (yet) available and
• Not affected

Then also with this approach we can't tell if fix is almost ready and currently being tested by QA but is not released yet.
We would like to change this approach where possible and fix these limitations. So Oval files comes for the rescue

Now for SUSE products, we already have this information in the Oval files provided by SUSE security team. For all other distribution, I am not aware if we have this information available in oval files provided by their vendor.

For the codebase, I would recommend setting up the dev env and start playing with the CVE audit feature. To setup the development env, these links could be helpful https://github.com/uyuni-project/uyuni/wiki/Java-Development-Environment and https://github.com/uyuni-project/uyuni/wiki/Uyuni-development-in-no-time

For debugging, this would come handy https://github.com/uyuni-project/uyuni/wiki/Development-Environment-Alternative-Instructions

Most of the CVE audit related code resides in this directory, at least the backend code https://github.com/uyuni-project/uyuni/tree/master/java/code/src/com/redhat/rhn/manager/audit

General documentation about feature is here https://www.uyuni-project.org/uyuni-docs/en/uyuni/reference/audit/audit-cve-audit.html

[Bhavya031]

@admd Could you please review my GSOC proposal? Additionally, I have noticed a lack of activity regarding GSOC in Uyuni's Gitter chat. Is there another chat I should use, or are people in the Gitter chat not very active?

[admd]

Dear @Bhavya031

Thank you for submitting your proposal. Upon review, I find it to be good. As for communication, I suggest utilizing Gitter chat, yes there may be delays in response times but gitter is the only chat platform that we use when it comes to Uyuni.

Thank you for your understanding.

[cbosdo]

We should close it as the project is done.