Open istaveren opened 2 years ago
(Disclaimer: I'm in the Oracle Linux support/development group.)
Basically this is similar to issue #736.
Oracle Linux ships with up to three flavors of system packages for different purposes:
The user determines which flavor is installed based on their system requirements, but Oracle issues advisories (ELSAs) and related OpenSCAP (OVAL) data for all three flavors. So scanning all available ELSAs will result in false positives if the ELSA is for a different flavor than the one installed.
Basically, scans should do a heuristic to determine whether to apply an ELSA to the system, with the following logic:
_fips
, only scan against this ELSA if the installed package(s) include _fips
in the version string..ksplice
, only scan against this ELSA if the installed package(s) include .ksplice
in the version string.Note that these apply to the version string component of the package and not the package name, but inclusion of the leading _
and .
in cases 1 and 2 respectively should ensure that this is done correctly.
This logic should be applied to both OL7 and OL8. Whether this should be a rule added to each ELSA scan or at some higher level I don't know, that depends on how Trivy is structured.
If this needs to be at a per-DB-entry level, you can limit the special-case logic to only the packages covered by that special case:
FWIW please feel free to email me at my work email address (todd.vierling@oracle.com) if any clarification is needed on the above, we're happy to help Trivy developers on any Oracle Linux related issue.
This issue is stale because it has been labeled with inactivity.
Unstale
istaveren, my temporary workaround for this issue is:
FROM oraclelinux:8
RUN set -ex && \
microdnf update && \
microdnf install dnf && \
dnf -y install https://yum.oracle.com/repo/OracleLinux/OL8/4/security/validation/x86_64/getPackage/gnutls-3.6.16-4.0.1.el8_fips.x86_64.rpm && \
dnf -y install https://yum.oracle.com/repo/OracleLinux/OL8/4/security/validation/x86_64/getPackage/libgcrypt-1.8.5-7.el8_6_fips.x86_64.rpm && \
microdnf clean all && \
rm -rf /tmp/* /var/cache/dnf/* /var/cache/yum/* /var/lib/dnf/* /var/lib/rpm/*
This issue is stale because it has been labeled with inactivity.
Unstale
This issue is stale because it has been labeled with inactivity.
istaveren, my temporary workaround for this issue is:
FROM oraclelinux:8 RUN set -ex && \ microdnf update && \ microdnf install dnf && \ dnf -y install https://yum.oracle.com/repo/OracleLinux/OL8/4/security/validation/x86_64/getPackage/gnutls-3.6.16-4.0.1.el8_fips.x86_64.rpm && \ dnf -y install https://yum.oracle.com/repo/OracleLinux/OL8/4/security/validation/x86_64/getPackage/libgcrypt-1.8.5-7.el8_6_fips.x86_64.rpm && \ microdnf clean all && \ rm -rf /tmp/* /var/cache/dnf/* /var/cache/yum/* /var/lib/dnf/* /var/lib/rpm/*
Thanks , this was helpful. It was easy to apply patch than convincing security guys that it is false positive .
In my Open-Source project Drifty, two docker images are published namely drifty-cli
and drifty-gui
with their base runtime images being [oraclelinux:9-slim
](). I use Trivy to check for vulnerabilities and recently, I started using Copa and it could fix only some vulnerable packages except the FIPS ones.
Currently, Trivy reports gnutls
and nss
packages to be vulnerable in oraclelinux:9-slim
docker image but docker scout
did not report such vulnerability. Is the report false positive? Please let me know.
Some reference CVE links provided by Trivy:
@knqyf263 May I know the progress of this issue? This terrible bug is causing problem to manually mark them false positive.
Description
When you scan an oraclelinux:8 image
What did you expect to happen?
There should not be any issue
It thinks I need 10:1.8.5-6.el8_fips -> https://linux.oracle.com/errata/ELSA-2022-9263.html Where https://github.com/aquasecurity/vuln-list/blob/main/oval/oracle/2021/ELSA-2021-4409.json looks ok.
Related to #issue 736
What happened instead?
I got vulnerabilities
Output of run with
-debug
:Output of
trivy -v
:Additional details (base image name, container registry info...):