policy for seccomp-profile selection

[vrothberg]

Implement a policy for selecting a seccomp profile. In addition to the
default behaviour (default profile unless --security-opt seccomp is set)
add a second policy doing a lookup in the image annotation.

If the image has the "io.containers.seccomp.profile" set its value will be
interpreted as a seccomp profile. The policy can be selected via the
new --seccomp-policy CLI flag.

Once the containers.conf support is merged into libpod, we can add an
option there as well.

Note that this feature is marked as experimental and may change in the
future.

Signed-off-by: Valentin Rothberg rothberg@redhat.com

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vrothberg

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vrothberg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vrothberg]

Note that tests are still missing. I will push an image to Quay that we can use for testing.

[vrothberg]

@rhatdan @mheon PTAL for an initial discussion.

[vrothberg]

Still need to add tests. @baude gave me access to the libpod project on Quay where I'll push an image with a seccomp profile.

[vrothberg]

Now with tests

[vrothberg]

@vbatts WDYT?

[mheon]

I don't see where this is actually consumed - where are we trying to decode/use the image seccomp annotation

[vrothberg]

We're doing that in pkg/spec.getSeccompConfig

[vrothberg]

Dang. We can't use Quay as docker v1 doesn't support annotations -.-

[vrothberg]

The images are now at docker.io/libpod/alpine-with.... Note that Docker Hub still has bugs with OCI images. I first had to push the images in docker s2v2 to properly create the repository/namepsace and then pushed the OCI images.

[vbatts]

Dang. We can't use Quay as docker v1 doesn't support annotations -.-

you can request your repo on quay to be switched to v2.s2

[NevilleC]

As there is a return inside the if clause, you could happy path this.

[rhatdan]

I believe we could do this by default, iff we could determine the seccomp file specified in the image has less access then the default policy. Then we don't need the user to be involved in the decision. In my opinion, if the user has to be involved, then no one will use it. I could see the developer of the image going and specifying a locked down seccomp filter.

The problem is whether or not the image should be trusted to specify its own security constraints. If the image can specify limited seccomp rules, that are provable more secure, then we could use by default. For that matter we could also add annotations to the image to specify the list of capabiltiies required by the container. Which would be even easier for the developer to access, then the container engine compares the list of capabilities to its default list and runs the container with less or fails to run if the image requires more caps, then the caller specified....

[vrothberg]

I believe we could do this by default, iff we could determine the seccomp file specified in the image has less access then the default policy. Then we don't need the user to be involved in the decision. In my opinion, if the user has to be involved, then no one will use it. I could see the developer of the image going and specifying a locked down seccomp filter.

The problem is whether or not the image should be trusted to specify its own security constraints. If the image can specify limited seccomp rules, that are provable more secure, then we could use by default. For that matter we could also add annotations to the image to specify the list of capabiltiies required by the container. Which would be even easier for the developer to access, then the container engine compares the list of capabilities to its default list and runs the container with less or fails to run if the image requires more caps, then the caller specified....

Doing that for capabilities is much easier as it boils down to diff slices of strings. Doing that for seccomp files is much harder where we'll soon run into difficult choices:

• What if the filters are conditional (e.g., based on arguments or even on certain values of certain arguments)?

Such choices might be answered differently depending on the person or use-case etc. Hence, I feel rather objective to implement comparing the seccomp profiles.

I believe we could do this by default, iff we could determine the seccomp file specified in the image has less access then the default policy.

I don't think we can do this reliably (see comments above). I believe that a policy such as suggested in this PR is the way forward. It somehow boils down to the questions whether we can trust an image. If we are concerned that an image could open the fence via a less secure seccomp profile, then we should check and inspect the entire image in any case. For instance, an image might specify volumes and send them to a remote server etc.

To give a different perspective/use case: Currently, seccomp profiles in OpenShift/Kubernetes must reside on the host. With this PR (assuming we'll lift it to the K8s world) we can attach profiles to the image and make seccomp portable. Certainly, we should only do this when we trust the image. If we don't then there's a whole load of other things we must disable.

One use case might be to further tighten the security, another might be to explicitly allow certain syscalls which might be needed for a certain image. So we have opt-in AND opt-out use cases. In the opt-out case, we could have a much tighter default profile and use the image to opt-out. I think this is another example for not comparing seccomp profiles: How do we measure more or less secure?

[rhatdan]

Doing that for capabilities is much easier as it boils down to diff slices of strings. Doing that for seccomp files is much harder where we'll soon run into difficult choices:

Not sure I agree. If we run the hosts seccomp files and the images seccomp files through the same algorithm to fire off the filters and get the final list of syscalls available to the container. If image lists contains a syscall not listed in the host list, then container is blocked.

[vrothberg]

Not sure I agree. If we run the hosts seccomp files and the images seccomp files through the same algorithm to fire off the filters and get the final list of syscalls available to the container. If image lists contains a syscall not listed in the host list, then container is blocked.

We don't have a list of syscalls. We have a list of rules and those are conditional. An image might specify to only allow/block a syscall when an argument has a certain value. And that's where it's getting hairy as some might argue that a conditional blocking of an argument is safer or more dangerous or just needed for the sake of portability.

In the end, this PR allows to add more policies in the future. I would still vote the "default" policy to mean "default chosen by the podman". We can still add a "fallback" policy in the future.

[mheon]

What about calls that block individual arguments? Whitelist vs blacklist? I remember looking into something similar (but composing the two profiles together instead) and abandoning it because it did not seem possible.

…

On Mon, Jan 13, 2020, 13:04 Daniel J Walsh ***@***.***> wrote: Doing that for capabilities is much easier as it boils down to diff slices of strings. Doing that for seccomp files is much harder where we'll soon run into difficult choices: Not sure I agree. If we run the hosts seccomp files and the images seccomp files through the same algorithm to fire off the filters and get the final list of syscalls available to the container. If image lists contains a syscall not listed in the host list, then container is blocked. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4806>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCGAYRHEEZUTRDU64S3Q5SULDANCNFSM4KD3KNGA> .

[vrothberg]

What about calls that block individual arguments? Whitelist vs blacklist? I remember looking into something similar (but composing the two profiles together instead) and abandoning it because it did not seem possible.

That's exactly my concern as well. We could drive some heuristics when comparing but I don't think that's user friendly. I feel objective to semantics that exceed an if-then-else in the docs.

[rhatdan]

I think there is a list of syscalls that end up being loaded into the kernel. This list is done by prepossessing all of the capabilities to get the final list. I think we could get pretty close to the correct list. Then we could look at syscalls that have specific fields, and force the user to override then, since it gets difficult. In the general case, I believe we could tell the difference.

[vrothberg]

Alright. @rhatdan and I agreed to merge this PR as is but to also look into the idea to create a policy that only uses the image's seccomp profile if it doesn't allow syscalls that are blocked by the default profile.

[rhatdan]

/lgtm