vex: allowlist runtime kernel packages for ingestion - #1967
Conversation
33a44c2 to
c1fba0f
Compare
|
This is how things looks from a DB perpective. Feed: Old /vex/ Feed: New /vex-feed/ |
Some container images (kubevirt, bootc, driver-toolkit) ship real kernel RPMs. Replace the blanket kernel-* reject with an allowlist of runtime packages so those advisories can match, while still filtering headers/docs/debuginfo that commonly appear in userspace images. Signed-off-by: crozzy <joseph.crosland@gmail.com>
c1fba0f to
3a7d31d
Compare
crozzy
changed the title
BradLugo
left a comment
BradLugo
left a comment
There was a problem hiding this comment.
Implementation looks pretty good to me. Have some notes on the allow list.
minor nit:
I don't think we usually capitalize the first word in a scope git summary.
I ran an experiment last Friday comparing data from main with the changes from this PR. I found similar findings as Crozzy; there were 319,352 kernel vulns (from the old VEX feed), and I spot-checked some results from an image that included the kernel-core package. It all seemed good to me.
| "kernel", | ||
| "kernel-core", | ||
| "kernel-modules", | ||
| "kernel-modules-core", | ||
| "kernel-modules-extra", | ||
| "kernel-devel", |
There was a problem hiding this comment.
I don't think we'd want kernel-devel. I think we'd want some additions too. Here's what I propose:
| "kernel", | |
| "kernel-core", | |
| "kernel-modules", | |
| "kernel-modules-core", | |
| "kernel-modules-extra", | |
| "kernel-devel", | |
| "kernel", | |
| "kernel-core", | |
| "kernel-modules", | |
| "kernel-modules-core", | |
| "kernel-modules-extra", | |
| // unified kernel image | |
| "kernel-uki-virt", | |
| "kernel-uki-virt-addons", | |
| // realtime | |
| "kernel-rt", | |
| "kernel-rt-core", | |
| "kernel-rt-kvm", | |
| "kernel-rt-modules", | |
| "kernel-rt-modules-core", | |
| "kernel-rt-modules-extra", | |
| // aarch64 | |
| "kernel-64k", | |
| "kernel-64k-core", | |
| "kernel-64k-modules", | |
| "kernel-64k-modules-core" | |
| "kernel-64k-modules-extra" | |
| // realtime aarch64 | |
| "kernel-rt-64k", | |
| "kernel-rt-64k-core", | |
| "kernel-rt-64k-kvm", | |
| "kernel-rt-64k-modules", | |
| "kernel-rt-64k-modules-core", | |
| "kernel-rt-64k-modules-extra", |
Might also want to add the kernel-debug-related packages.
There was a problem hiding this comment.
@vojtapolasek do you have some view on this?
There was a problem hiding this comment.
I agree with @BradLugo. Just for the context, I am collaborating on a project which is a wrapper around clair and scans running systems, not only containers. And kernel is obviously present on these systems.
I also agree that kernel-devel and kernel-headers are not needed in this filter, at least for now.
Extending the list and merging the PR as noted in @BradLugo comment would drastically decrease number of false negatives we currently get, because kernel packages are just ignored now.
There was a problem hiding this comment.
Did you mean to add this? I suspect it was meant to be part of some other rhcos work, but not sure.
There was a problem hiding this comment.
Same question here; did you mean to add this?
This patch gives the operator the ability to restore previous behaviour of the RHEL VEX parser to ignore kernel vulnerabilities. setting the ingore_kernel_packages flag to true will also change the updater fingerprint and force a full update (as will subsequently removing it/setting it to false). Signed-off-by: crozzy <joseph.crosland@gmail.com>
3a7d31d to
c643efc
Compare
3 participants
No description provided.