[ Question ] Clair support for clearlinux

[ldelossa]

Hello,

I work on a RedHat sponsored open source project. https://github.com/quay/claircore and https://github.com/quay/clair

We provide container vulnerability information for containers. I am recently a personal user of Clear Linux and I'm excited about the project.

I'd be interested in building Clear Linux support into Clair. Does Clear Linux have it's own security tracker? Does Clear Linux have any stance on CVE tracking and reporting via SWUPD ?

[bryteise]

Moving this over to a better spot. Currently we do have internal facing tools for CVE tracking but we haven't added hooks into swupd itself to use those to do reporting. We have some a potential project to help with external reporting but it is still under development. It looks like Clair does on system scanning and makes use of knowledge about layers (but could work on non-container systems just as well). I note that for some of our containers there isn't any local information about a package database (or even swupd!) but the os version dictates all the versions of software in use as a singular number so that isn't a blocker. We do some patching for CVEs outside of version updates how does Clair track those?

[ldelossa]

Typically Clair takes the following approach.

A series of container layers are presented to Clair. Clair attempts to identify the distribution and a package database within each layer. Clair parses the packages found within the package database, and tags them with the distribution information found.

Clair also parses distribution security trackers. These are usually Oval databases maintained by the distro. Clair relies on this source of information as it's fine tuned for the distros we support. We will look at general CVE data from NIST, but this is not supported currently.

So as of today, we really expect there to be a consistent "os-release" file (or another file we can consistently identify your distribution with) and a package database that we can parse.

Now I understand Clear linux uses bundled - we can also parse "bundles" installed, and then link them to CVE data you may have in a per-bundle fashion.

[bryteise]

Clear ships the standard os-release file and it is in the container images as well.

If swupd is around, you can get it to list installed bundles but that isn't super easy to relate to packages (and changes per release).

[fenrus75]

I suspect the binding desired is not so much to "package" as it is to "upstream project release"

that we publish online for each release in CSV form, but not inside the image

On Mon, Apr 20, 2020 at 3:36 PM William Douglas notifications@github.com wrote:

Clear ships the standard os-release file and it is in the container images as well.

If swupd is around, you can get it to list installed bundles but that isn't super easy to relate to packages (and changes per release).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/clearlinux/distribution/issues/1914#issuecomment-616847354, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ54FPBWUPANMIZTIROSZTRNTE5DANCNFSM4MMAD2BA .

[ldelossa]

Currently. what do your CVE's target. When a vulnerability affects a clear linux "bundle' do you create a CVE for this bundle, or are the CVE's targeting the contents (packages) of a clear linux bundle?

[ahkok]

Here's a quick run-through:

We track the CVEs for the underlying packages, since they correspond to actual CVE reports (obviously).

e.g. here's the list of underlying packages in release 32890:

https://download.clearlinux.org/releases/32890/clear/source/package-sources

Note that we store patches in git repos, including CVE patches. You'd have to figure out the base CVEs for each package from upstream CVE sources, then subtract things we've fixed or marked as "nopatch" to indicate they CVE doesn't apply to ClearLinux (e.g. arch dependent or vulnerable code isn't enabled in our builds). Those are at github.com/clearlinux-pkgs. The NVR's in the package-sources file correspond to git tags in clearlinux-pkgs.

To resolve "packages" into "bundles" you currently need to rely on full RPM dependency resolution, which we do using dnf, to go from packages to bundles using the mapping in github.com/clearlinux/clr-bundles.

This is all possible but complex and very tedious right now.