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

Adding setcap to the Dockerfile causes the HasModifiedFiles check in Preflight 1.6.1 to fail #969

Closed
tkrishtop opened this issue Apr 28, 2023 · 3 comments · Fixed by #970
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@tkrishtop
Copy link
Contributor

Bug Description

Adding setcap to the Dockerfile causes the HasModifiedFiles check in Preflight 1.6.1 to fail.

Version and Command Invocation

1.6.1

Steps to Reproduce:

  1. Build an image quay.io/tkrishtop/setcap-example:v0.0.2 using the Dockerfile below:
FROM registry.access.redhat.com/ubi8/ubi:8.7-1112

RUN microdnf -y install iptables && \
    microdnf clean all

RUN setcap CAP_NET_ADMIN,CAP_NET_RAW+eip /usr/sbin/xtables-nft-multi

CMD [ "cat", "hello world"]
  1. Run the Preflight check and observe the HasModifiedFiles check fail:
podman run -e PFLT_LOGLEVEL=trace quay.io/opdev/preflight:1.6.1 check container quay.io/tkrishtop/setcap-example:v0.0.2

-- snip --

time="2023-04-28T07:38:06Z" level=debug msg="found disallowed modification in layer" file=usr/sbin/xtables-nft-multi layer="sha256:0765ec7ff35e3e077fb047f7a8710cdcef9c2ad08877fce70f25c94492b8a213"
time="2023-04-28T07:38:06Z" level=info msg="check completed" check=HasModifiedFiles result=FAILED
  1. Confirm that the issue is caused specifically by the setcap line: setcap CAP_NET_ADMIN,CAP_NET_RAW+eip /usr/sbin/xtables-nft-multi by building another image quay.io/tkrishtop/setcap-example:v0.0.3 without setcap:
FROM registry.access.redhat.com/ubi8/ubi:8.7-1112

RUN microdnf -y install iptables && \
    microdnf clean all

CMD [ "cat", "hello world"]

This image passes the HasModifiedFiles check

$ podman run -e PFLT_LOGLEVEL=trace quay.io/opdev/preflight:1.6.1 check container quay.io/tkrishtop/setcap-example:v0.0.3

-- snip --

time="2023-04-28T10:10:45Z" level=info msg="check completed" check=HasModifiedFiles result=PASSED

Expected Result

Telco partners often require the use of setcap:

CAP_NET_ADMIN - Allow various network-related operations (e.g., setting privileged socket options, enabling multicasting, interface configuration, modifying routing tables).
CAP_NET_RAW - Permit use of RAW and PACKET sockets.

Containers using setcap do nothing wrong or non-standard, they should pass the certification checks.

Actual Result

check=HasModifiedFiles result=FAILED

Additional Context

Since there is no solution on our side, this issue is becoming urgent and has the potential to impact many Telco partners.

cc: @bcrochet @acornett21

@tkrishtop tkrishtop added the kind/bug Categorizes issue or PR as related to a bug. label Apr 28, 2023
@bcrochet bcrochet self-assigned this Apr 28, 2023
@bcrochet
Copy link
Contributor

This should not be a failure. I'm working on a solution. I've identified what happens in the layer that causes this. The problem is not making it so broad of a fix that other things slip through.

bcrochet added a commit to bcrochet/openshift-preflight that referenced this issue Apr 28, 2023
If a file in a layer has had setcap used on it, it will show up in
the layer, but be unchanged. However, there will be a PAX record
that shows the extended attrs. For now, preflight will ignore these
files, unless/until we find a situation where we should be more robust
in this check and possibly fail it.

Fixes redhat-openshift-ecosystem#969

Signed-off-by: Brad P. Crochet <brad@redhat.com>
acornett21 pushed a commit that referenced this issue May 1, 2023
If a file in a layer has had setcap used on it, it will show up in
the layer, but be unchanged. However, there will be a PAX record
that shows the extended attrs. For now, preflight will ignore these
files, unless/until we find a situation where we should be more robust
in this check and possibly fail it.

Fixes #969

Signed-off-by: Brad P. Crochet <brad@redhat.com>
@tkrishtop
Copy link
Contributor Author

Hi @bcrochet @acornett21 thank you for the fix. Could you please let us know when do you plan to release Preflight containing this fix?

@acornett21
Copy link
Contributor

@tkrishtop We are waiting on a change in go-rpmdb to be merged and referenced in preflight before we cut a release. Reference to PR here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants