Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False positives due to a layer having different parents #319

Closed
MrTrustor opened this issue Feb 17, 2017 · 2 comments
Closed

False positives due to a layer having different parents #319

MrTrustor opened this issue Feb 17, 2017 · 2 comments
Labels
kind/design relates to the fundamental design of a component

Comments

@MrTrustor
Copy link

Hello,

First of all, thank you for your work, Clair is an impressive software.

We are using Clair internally for our private repositories and we ran into the issue described in #68. To sum up: Clair is not aware of the whole chain of layers that make up a Docker image. As a layer is identified by its content, you can have the same layer in different images, with different parents, leading to false positives (or false negatives).

Here is how we ran into the problem:

  1. We built an image FROM grafana/grafana:4.1.1. Clair informed us that there were some vulnerabilities in this image (because it was not built from the latest debian:jessie image). The Dockerfile looks like this:
FROM grafana/grafana:4.1.1
COPY file1 /foo
COPY file2.sh /bar
ENTRYPOINT ['/bar/file2.sh']
  1. To fix the problem, we took the Dockerfile from grafana/grafana:4.1.1 and sourced our image directly from the latest debian:jessie:
FROM debian:jessie
ARG DOWNLOAD_URL
RUN apt-get update && \
    apt-get -y --no-install-recommends install libfontconfig curl ca-certificates && \
    apt-get clean && \
    curl ${DOWNLOAD_URL} > /tmp/grafana.deb && \
    dpkg -i /tmp/grafana.deb && \
    rm /tmp/grafana.deb && \
    curl -L https://github.com/tianon/gosu/releases/download/1.7/gosu-amd64 > /usr/sbin/gosu && \
    chmod +x /usr/sbin/gosu && \
    apt-get remove -y curl && \
    apt-get autoremove -y && \
    rm -rf /var/lib/apt/lists/*
EXPOSE 3000
COPY file1 /foo
COPY file2.sh /bar
ENTRYPOINT ['/bar/file2.sh']

The last few layers are the same in the 2 resulting images, but the parents are not. In the first case, the parents have some vulnerabilities while they have not in the second (they have only vulnerabilities for which there is no fix).

When POSTing the layers of the second image to Clair, we got a 201 status code, but the parent of the layers were not updated in the database. So, when fetching the vulnerabilities for the last layer of the second image, we actually got the vulnerabilities of the first image.

In #68, it is said that the issue has been identified and put into the roadmap, but the current roadmap makes no mention of it. Is this problem still identified somewhere?

@MrTrustor
Copy link
Author

Any answer to this?

KeyboardNerd pushed a commit to KeyboardNerd/clair that referenced this issue Feb 2, 2018
Presently the layer and namespace tables use type `varchar(128)` for
their respective name columns. For layer, this width works fine enough
using the sha256 digests provided by docker. However, if one wishes to
encode the image name into the layer  name (eg, to avoid collisions like
in [0]), the limit of 128 bytes starts to feel a bit cramped. Bump to
256 bytes, since that "ought to be enough for anybody." (TM)

[0]: quay#319
@jzelinskie
Copy link
Contributor

This issue does not effect Clair v3 as we force users to post all the layers in an image upfront and we do not conflate relationships outside of that specified ancestry.

@jzelinskie jzelinskie added kind/design relates to the fundamental design of a component component/api labels Sep 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/design relates to the fundamental design of a component
Development

No branches or pull requests

2 participants