[REQ] Add Oracle Linux as supported OS

[slowjoe007]

What kind of request is this?

New feature

What is your request or suggestion?

Currently, Oracle Linux (https://hub.docker.com/_/oraclelinux) cannot be patched and the following error message is shown:

Error: unsupported osType oracle specified

Please, add support for Oracle Linux.

Note: Oracle Linux 7 uses yum, while starting with version 8 dnf is used as package manager.

[sozercan]

looks like there are fips packages in non-fips images that are causing issues due to versioning checks. This will need further investigation.

* downloaded package libgcrypt version 1.8.5-7.el8_6 lower than required 10:1.8.5-7.el8_6_fips for update https://github.com/project-copacetic/copacetic/actions/runs/5625368437/job/15244418767?pr=207#step:6:2476

[MiahaCybersec]

Oracle was attempted to be added in PR #207 but the PR had to be closed due to an update error. For some reason, Copa will throw an error similar to the one below despite no fips packages being present in the non-fips version of Oracle.

* downloaded package libgcrypt version 1.8.5-7.el8_6 lower than required 10:1.8.5-7.el8_6_fips for update

Note that this error appears to be present on all Oracle 7 and 8 versions. I've been unable to reproduce this bug with any Oracle 9 releases.

Reproducing The Bug

docker pull aquasec/trivy

Download the Copa codebase from my fork and run make in the root of the project. In the commands below, all files and directories were kept in my home folder.

unzip copacetic-oracle.zip cd copacetic-oracle make cd /dist/linux_amd64/release

Run the Trivy scan and save output in the release folder. This is just for testing to simplify commands.

docker run aquasec/trivy -f json image oraclelinux:8.8 > ./oracle8.8-scan.json

Attempt to patch the image with the json Trivy just gave us.

./copa patch -r ./oracle8.8-scan.json -i docker.io/library/oraclelinux:8.8

If you get an error that says Error: could not use docker driver: failed to solve: requested experimental feature mergeop has been disabled on the build server: only enabled with containerd image store backend, add the following to /etc/docker/daemon.json and restart the service with sudo systemctl restart docker. Then try to run the Copa patch command again.

{
  "features": {
    "containerd-snapshotter": true
  }
}

We should get the error shown at the top of this comment. What makes this bug rather odd is that the package throwing the error is a non-fips package. To verify this we run the following commands.

docker run -it oraclelinux:8.8 yum deplist libgcrypt

There is a dependency on fipscheck, but this does not inherently mean that the package is compiled with fips support.

The Root Cause & The Solution

This issue is caused by Oracle shipping up to 3 versions of system packages for different purposes:

• Normal
• Ksplice Userspace
• FIPS-validated

But Oracle ships ESLAs and OpenSCAP (OVAL) data for all three flavours. Scanning all available ESLAs will result in false positives if the ELSA is for a different flavor than the one installed.

Scans should do a heuristic to determine whether to apply an ELSA to the system, with the following logic:

• If the ELSA package version string contains _fips, only scan against this ELSA if the installed package(s) include _fips in the version string.
• If the ELSA package version string contains .ksplice, only scan against this ELSA if the installed package(s) include .ksplice in the version string.
• Otherwise, scan as normal.

The above explanation was found in this issue: https://github.com/aquasecurity/trivy/issues/1967

[MiahaCybersec]

Due to the non-standard way that Oracle handles this, I propose the Copa team to take one of three implementations.

• Add a patch to Trivy upstream to resolve this issue
• Decide Oracle isn't first class support, add that to docs and close the issue
• Add a patch to Copa to handle this edge case scenario

I believe options one and two to be the best approaches, but Copa could modify the way packages are patched if the team believes that is the best route to take. Any input on this @ashnamehrotra @sozercan?

[ashnamehrotra]

Thank you for investigating this @MiahaCybersec! I agree, I don't think we should hard code this edge case scenario in Copa. Depending on the priority of this issue, it could be worth adding a patch to Trivy upstream, @sozercan may have a better idea.

[sozercan]

@ashnamehrotra will this work with the new update all functionality? is blocker only on the scanner front?

[ashnamehrotra]

@sozercan yes that is correct, with update all we wouldn't get this issue.