BUG: Cache failure in docker without root when container is immutable

[chen-keinan]

Discussed in #4286

^{Originally posted by tspearconquest October 18, 2022}

Description

Hello,

In my CI pipeline, I'm trying to use the Trivy docker image without root permissions to scan tarball artifacts.

In our environment, we maintain an internal copy of the docker image which gets updated once per hour with the latest trivy db, and we place that in the path /trivycache and recently I wanted to convert it to non-root.

My Dockerfile is 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 '{}' \;

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. However, it seems that keeping the db in the cache directory probably not desirable for our use case, as this is also causing the cache to be unwritable, which I think is an error.

I am running this image in my CI pipeline and we don't have a desire to create a redis instance for this purpose, so I am hoping you could provide 2 new flags.

1. --db-dir for specifying the path for the trivy db separately from the cache directory.
2. --no-cache for specifying not to use the cache at all.

In our case, the image is intended to be immutable and we won't make use of the fanal cache, hence writing to it is not necessary.

What did you expect to happen?

Expected for the --cache-dir to only be used by the vulnerability db, and was not aware of the fanal cache.

After investigating and taking a look at harbor issue 16606, I found out that fanal db is the os package cache for Trivy and so Trivy is always trying to write to it during our scans by the pipeline.

What happened instead?

The --cache-dir is used for both the vulnerability db and the fanal cache, so when I changed the permissions to root for the whole directory, it prevents non-root trivy from running.

Output of run with -debug:

❯ docker run --rm -it --entrypoint "" registry.gitlab.com/my-private-repo/trivy-image/trivy:latest-non-root /bin/sh

/ $ trivy --cache-dir=/trivycache fs --skip-update .
2022-10-18T20:30:19.229Z	FATAL	init error: cache error: unable to initialize the cache: unable to initialize fs cache: unable to open DB: open /trivycache/fanal/fanal.db: permission denied

/ $ trivy --debug --cache-dir=/trivycache fs --skip-update .
2022-10-18T20:30:23.375Z	DEBUG	Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2022-10-18T20:30:23.376Z	FATAL	init error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.Run
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:362
  - cache error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.NewRunner
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:116
  - unable to initialize the cache:
    github.com/aquasecurity/trivy/pkg/commands/artifact.(*runner).initCache
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:308
  - unable to initialize fs cache:
    github.com/aquasecurity/trivy/pkg/commands/operation.NewCache
        /home/runner/work/trivy/trivy/pkg/commands/operation/operation.go:69
  - unable to open DB:
    github.com/aquasecurity/trivy/pkg/fanal/cache.NewFSCache
        /home/runner/work/trivy/trivy/pkg/fanal/cache/fs.go:30
  - open /trivycache/fanal/fanal.db: permission denied

Output of trivy -v:

/ $ trivy -v
Version: 0.32.1

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

[chen-keinan]

this issue requirement more urgent for for tirvy-operator use case aquasecurity/trivy-operator#1342

Related: aquasecurity/trivy-operator#1574

[chen-keinan]

Proposed solution by @knqyf263 separate cache directories :

You can set different permissions to the following directories.

/trivycache/fanal
for image cache
/trivycache/db
for vulnerability database