BUG: 2 Vulnerability DB related failures in docker without root when container is immutable

[tspearconquest]

Description

In #3040 I reported that it is not possible to run Trivy in an immutable container due to Trivy trying to write to the cache.

This issue is similar but reporting a bug with the --skip-db-update flag.

I have tweaked my Dockerfile to allow for the fanal.db to be writable and attempted again to run Trivy.

My Dockerfile now looks as below:

ARG BUILDER_VERSION
ARG BUILDER_TYPE
ARG IMAGE_VERSION
ARG IMAGE_TYPE
FROM aquasec/trivy:${IMAGE_VERSION}${IMAGE_TYPE} as builder
USER 65532

FROM alpine:3.16 as image
USER 0

COPY --from=builder /usr/local/bin/trivy /usr/local/bin/trivy
COPY --from=builder /contrib /contrib

ENV PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

RUN addgroup -S -g 65532 trivy \
 && adduser -S -D -H -u 65532 -g 65532 trivy \
 && mkdir -p /trivycache \
 && trivy --cache-dir /trivycache image --download-db-only --no-progress \
 && chown -R root. /trivycache \
 && find /trivycache -type d -exec chmod 755 '{}' \; \
 && find /trivycache -type f -exec chmod 644 '{}' \; \
 ## Change the ownership of the cache db back to trivy so it can be written to
 ## Remove this line if https://github.com/aquasecurity/trivy/issues/3040 results in 2 new flags
 && chown trivy. /trivycache/fanal/fanal.db

USER 65532

ENTRYPOINT [ "trivy", "--cache-dir=/trivycache" ]

As you can see, I have set the permissions to prevent the user account from overwriting the cache directory where the database is currently stored.

I do this for security reasons to protect the db from being overwritten. Because we download the DB once per hour in our pipeline, we are expecting to be able to have the image be completely immutable, but it seems that even with the --skip-db-update flag, Trivy is still trying to write to the path /trivycache/db/trivy.db

What did you expect to happen?

Now that I changed the file permissions on /trivycache/fanal/fanal.db, I expected that Trivy would honor the --skip-db-update flag, and simply open the file /trivycache/db/trivy.db for reading, but not writing.

What happened instead?

It appears based on the debug output below, that the flag is not being honored completely.

When I looked into the code, I found that the NewRunner function is correctly taking the --skip-db-update flag, however it is not checking the flag in this code. Instead it is passing it straight to initDB on line 120.

Furthermore, in the initDB function, I can see that it is also correctly taking the flag, however in here it also is not checking the flag. I can see the flag is passed on to DownloadDB in line 275. This function succeeds, and then the code continues on to db.Init on line 283.

From there, it is passed into the aquasecurity/trivy-db module code in the Init function on line 61 of db.go wherein there is a sanity check of the DB which tries to delete the DB if it is corrupt, or tries to open the DB with write permission on line 76.

This DB was just freshly downloaded since I had just created this image, so it appears that there are 2 bugs.

The first bug is that the DB should not be erased if it is corrupt when the --skip-db-update flag is passed.
Instead it should throw an error about the DB being corrupt, and Trivy should exit.

The second bug is that the code should not be trying to open the DB with write permissions when --skip-db-update is passed on the command line.

Output of run with -debug:

❯ docker run --rm -it --entrypoint "" registry.gitlab.com/armed-atk/development/devsecops/images/trivy/trivy:v0.32.1-57 /bin/sh                             1m 19s
/ $ trivy --debug --cache-dir=/trivycache fs --skip-db-update .
2022-10-18T21:29:02.808Z	DEBUG	Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2022-10-18T21:29:02.813Z	DEBUG	cache dir:  /trivycache
2022-10-18T21:29:02.813Z	DEBUG	Skipping DB update...
2022-10-18T21:29:02.813Z	DEBUG	DB Schema: 2, UpdatedAt: 2022-10-18 18:12:27.474860418 +0000 UTC, NextUpdate: 2022-10-19 00:12:27.474860018 +0000 UTC, DownloadedAt: 2022-10-18 20:59:56.784414528 +0000 UTC
2022-10-18T21:29:02.814Z	FATAL	init error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.Run
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:362
  - DB error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.NewRunner
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:121
  - error in vulnerability DB initialize:
    github.com/aquasecurity/trivy/pkg/commands/artifact.(*runner).initDB
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:284
  - failed to open db:
    github.com/aquasecurity/trivy-db/pkg/db.Init
        /home/runner/go/pkg/mod/github.com/aquasecurity/trivy-db@v0.0.0-20220627104749-930461748b63/pkg/db/db.go:83
  - open /trivycache/db/trivy.db: permission denied

Output of trivy -v:

/ $ trivy -v
Version: 0.32.1

Additional details (base image name, container registry info...):

[knqyf263]

Trivy currently needs to write cache somewhere. If you don't want, you can also use Redis.
https://aquasecurity.github.io/trivy/v0.32/docs/vulnerability/examples/cache/

[tspearconquest]

Hi, that's issue #3040 for the fanal.db. This is in regards to the trivy.db file which is not the cache.

Also, I mentioned we are using this in our pipelines so it's not feasible or reasonable to even have the cache.

[tspearconquest]

What did you expect to happen?

Now that I changed the file permissions on /trivycache/fanal/fanal.db, I expected that Trivy would honor the --skip-db-update flag, and simply open the file /trivycache/db/trivy.db for reading, but not writing.

[tspearconquest]

Currently trivy seems to require that the db is opened in read/write mode, even with --skip-db-update flag passed. This is the bug.

[knqyf263]

It is not saying it will open in read only. It just says it skips downloading the database.

[tspearconquest]

Yes, but if it is skipping downloading, Trivy should not need write permissions for trivy.db. So I am asking to fix the logic in opening the DB so if --skip-db-update is passed then it will open in readonly mode. :)

[knqyf263]

Yes, I know what you meant, so it is a feature request.

[github-actions[bot]]

This issue is stale because it has been labeled with inactivity.

[tspearconquest]

Please remove the stale lifecycle :)

[github-actions[bot]]

This issue is stale because it has been labeled with inactivity.

[tspearconquest]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been labeled with inactivity.