allow sys_chroot cap on SCCs

[pweil-]

Removes the requirement to drop chroot.

@smarterclayton

[pweil-]

@openshift/sig-security

[php-coder]

@bparees Should we allow this cap also to the building containers? Is it possible that we would need it?

[pweil-]

It is in the default set of caps from docker but we were requiring it to be dropped prior to this PR.

[php-coder]

@pweil- Was the previous comment, an answer to my question? I was asking about should we also remove it from this list:

origin/pkg/build/controller/strategy/sti.go

Line 35 in 7d661a2

"SYS_CHROOT",

[pweil-]

I was asking about should we also remove it from this list:

Seems reasonable to remove it there if we're removing it from restricted

[bparees]

what's the basis for us not requiring it to be dropped any longer? s2i is using that list of caps to drop because it runs the container directly, so it needs to manage the caps independently.

[pweil-]

sys_chroot is required by some of our containers that do scanning which led to our discussion of whether or not it should really be required as a drop. Ultimately, the chroot call is not considered a security feature of the kernel and folks are still relying on DAC and SELinux in order to protect the system.

Some references for posterity:

• https://access.redhat.com/blogs/766093/posts/1975883

The basic idea is that you can run a process inside of a chroot where it will not have access to various system resources; however, chroot is not a security feature.

• http://man7.org/linux/man-pages/man2/chroot.2.html

In particular, it is not intended to be used
for any kind of security purpose, neither to fully sandbox a process
nor to restrict filesystem system calls.

[bparees]

@pweil- ok in that case can you remove it from the spot @php-coder noted as well?

[pweil-]

updated

[bparees]

s2i change lgtm

[pweil-]

[test]

[openshift-bot]

Evaluated for origin test up to 2d59f8e

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/3230/) (Base Commit: 20e72f7) (PR Branch Commit: 2d59f8e)

[pweil-]

/assign @smarterclayton

bump for review

[php-coder]

PTAL @smarterclayton

[smarterclayton]

/lgtm

as well

[openshift-merge-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pweil-, smarterclayton

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these OWNERS Files:

• pkg/build/OWNERS [pweil-,smarterclayton]
• pkg/cmd/OWNERS [pweil-,smarterclayton]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[0xmichalis]

/retest

[openshift-merge-robot]

Automatic merge from submit-queue (batch tested with PRs 15834, 16321, 16353, 15298, 15433)

[enoodle]

@pweil- @bparees @php-coder
Hello,
Is this available in Openshift 3.7 (oc v3.7.27)? I am getting operation not permitted when trying to chroot inside a non privileged container.

[php-coder]

@enoodle Yes, it is:

$ git tag --contains 2d59f8e4c059df09e339e2bb0355cdbc6a78279e | grep 3.7
v3.7.0
v3.7.0-rc.0
v3.7.1

I'd suggest you to do the following:

• check by what SCC a pod was admitted (oc get pod <name> -o yaml | grep scc)
• check whether the output of the oc adm policy reconcile-sccs command is empty
• check whether a pod is requesting SYS_CHROOT capability in its securityContext

HTH

[enoodle]

Thanks for your help @php-coder I indeed had to request this capability directly.