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).