seccomp: allow specifying a custom profile with --privileged

[AkihiroSuda]

- What I did

Fix #47499

- How I did it

Updated daemon/seccomp_linux.go

- How to verify it

$ cat <<EOF >foo.json
{
 "defaultAction": "SCMP_ACT_ALLOW",
 "syscalls": [ { "names": [ "connect" ], "action": "SCMP_ACT_ERRNO" } ]
}
EOF

$ docker run --security-opt seccomp=foo.json --privileged busybox wget -O- http://1.1.1.1/
Connecting to 1.1.1.1 (1.1.1.1:80)
wget: can't connect to remote host (1.1.1.1): Operation not permitted

"Operation not permitted" is the expected error here.

- Description for the changelog

seccomp: allow specifying a custom profile with `--privileged`

- A picture of a cute animal (not mandatory but encouraged)
🐧

[neersighted]

I'm not sure this is correct or incorrect yet. As of late we have been discussing how --privileged and LSMs should combine (see the revival of #38075); so I'm registering my -1 for now until we decide how these options should (or should not) combine overall.

[AkihiroSuda]

To clarify the background, I'm proposing this for capturing socket syscalls with SCMP_ACT_NOTIFY to accelerate rootless containers: https://github.com/rootless-containers/bypass4netns

This is not an attempt to harden privileged containers beyond as it is.

[tonistiigi]

Overall LGTM and I think this is correct design.

But we should verify that all the individually controllable options also bundled into --privileged behave the same way. Atm. it looks like they do but it has not been verified and ideally should have individual test cases.

It would also be nice if there was a clear security scope definition(if there isn't already) , for example https://github.com/moby/buildkit/blob/master/PROJECT.md#security-boundary that would make it clear that --privileged is still considered insecure for security, no matter if you also use a different flag as well.

[thaJeztah]

@neersighted do you have a strong objection against this one? Overall, I think it's fine to do this, and it seems like a more logical option than silently discarding the user's preference (we should either error or accept, not "discard").

We should make sure that we're clear in the docs what the expectation is though; @dvdksn has a PR pending in the CLI;

• docs: clarify what the --privileged flag does docker/cli#4929

I think that one is "good enough" for now, but we should probably outline that even if we accept options like this, a --privileged container won't be able to provide full guarantees, as the reduced security could allow a compromised container to "undo" some of the (security) options that were set. (e.g., escaping the container's filesystem, and modify the container's config).

[neersighted]

Ah, circling back, we talked about this in a recent maintainers' call, and my takeaway is we probably should allow it, but we'd like to figure out what the semantics for all security-opt combinations with --privileged (ideally making them as consistent as possible) are and add some decent tests here, as the current semantics are quite unclear from the code.

I don't necessarily think we need to block everything on reaching that ideal state, but given there is more and more demand re: combining or decomposing --privileged, I think we need to make this happen sooner than later/spend some serious effort on it (cc @klueska).

[cpuguy83]

Maybe this should be connecting to a local service?

[AkihiroSuda]

Why?

[cpuguy83]

One of the tests is going to hit it, why make it hit an external endpoint?

[AkihiroSuda]

Sounds complicated, maybe the test should be modified to avoid socket syscalls ( if it is necessary to remove the dependency on 1.1.1.1)

[cpuguy83]

If you have another syscall in mind that seems ok.
The container could also setup netcat or something on localhost.

[cpuguy83]

Maybe the profile could block socket and we don't need to do anything special?