From a security perspective, I agree this isn't super great, but IMO it's not too much different from having a host that doesn't support either AppArmor or SELinux (users generally need to know/trust the security characteristics of the host/daemon they're running on), so I'm +1 on consistency here.

I applied two of your suggestions.

Remaining questions are (see above);

1. do we want the command-line flag to show "default" as default value, or do we prefer "" (empty string) to indicate "use the default" ?
2. word of choice for "default" as it is ambiguous when using on docker run; in that case "default" could be interpreted as either:
   • "default" (as configured on the daemon, which may not be the "default")
   • "default" (compiled-in, docker's default profile
3. Alternative names for the above: builtin or docker (or perhaps docker-default?)
4. If we decide to change the name, do we want to change what's shown in docker info as well? (Likely: "yes")

The other question to answer is: "do we want to allow unconfined" as a default? This was brought up by @tonistiigi. Motivation for that question was that (already possible since #26276) being able to set a non-standard seccomp profile as default on the daemon, causes inconsistency. A container may be able to run on "daemon A", but fail to run on "daemon B", because it uses a different configuration.

While custom profiles are "one thing", disabling seccomp altogether (using "unconfined" as a default) may be another thing, as it will be a less-secure configuration.

As said;

• this is already the case (and a "custom profile" could already be an empty profile, in which case the default is (roughly) the equivalent of "unconfined". If that's a real concern, then the only option would be to revert daemon: add a flag to override the default seccomp profile #26276
• also to add: while it's possible to make these changes in the daemon configuration, it's not the default, so it will be a conscious decision of the user. (not taking into account some distributions in which packagers include a custom profile and set this as default). In such a setup, docker info should print a WARNING that a non-standard profile is in use (so it's not "invisible").

Happy to get input / feedback on the above: @justincormack @tonistiigi @tianon @AkihiroSuda

Happy to get input / feedback on the above

I feel like I already opined, but I'll do so again 😇

do we want the command-line flag to show "default" as default value, or do we prefer "" (empty string) to indicate "use the default" ?

IMO that depends a little bit on whether users can specify the empty string to get the default back (and thus override a config file or similar) -- I think showing our explicit default string is probably clearer though in either case.

Alternative names for the above: builtin or docker (or perhaps docker-default?)

I like builtin, personally -- I think it clearly conveys what this value means.

If we decide to change the name, do we want to change what's shown in docker info as well?

yes 😄

do we want to allow unconfined as a default?

If users want this foot-cannon, it's something they can already accomplish, so I don't really see a compelling reason to add a special case in our code to try and stop it; at most, I'd think a warning -- do we do anything in particular when AppArmor or SELinux are either disabled or unavailable?

There are already a lot of settings available (both in Docker and outside Docker) that can affect the ability of arbitrary contains to successfully run, and so I don't think that's a very strong justification for denying it (especially when it's only a cosmetic denial that then simply requires more effort to accomplish via an empty profile). By that argument, we really shouldn't be allowing users to specify a new default profile at all. 😅

I started rebasing this one, and renaming s/default/builtin/, then realized we have the client-side warning that would need to be updated (I saw @cpuguy83 already found it 😅). Will continue the rename later today

@tianon @cpuguy83 I updated this:

• changed default to builtin (do we want it to be built-in or one word?)
• changed the --seccomp-profile flag to show the default (builtin) as default value

=== RUN TestDockerSuite/TestInfoSecurityOptions
docker_cli_info_unix_test.go:30: assertion failed: [name=apparmor name=seccomp,profile=builtin] does not contain name=seccomp,profile=default
--- FAIL: TestDockerSuite/TestInfoSecurityOptions (0.01s)

Ah, dang. Missed on

Updated! (hope it's green again now)

TestCreateServiceConfigFileMode also continues to be a pain; quite flaky

=== RUN   TestCreateServiceConfigFileMode
    create_test.go:355: assertion failed: 2 (int) != 1 (int)
--- FAIL: TestCreateServiceConfigFileMode (8.55s)

otherwise green, but let me kick CI again

Actually, I don't like that I'm now changing "default" to "builtin" in the first commit; that makes it hard to discover; let me move that to a separate commit; I'll ping when done

Not sure what changed, but definitely seeing more of these recently:

#59 [shfmt 1/1] RUN --mount=type=cache,target=/root/.cache/go-build     --mount=type=cache,target=/go/pkg/mod     --mount=type=bind,src=hack/dockerfile/install,target=/tmp/install         PREFIX=/build /tmp/install/install.sh shfmt
#59 sha256:5c49c7cdc1f31702c618c3d616ce7295fad095d629951a20eb8dcd3e334fe8c7
#59 618.6 error: RPC failed; curl 56 GnuTLS recv error (-54): Error in the pull function.
#59 618.6 fatal: the remote end hung up unexpectedly
#59 618.6 fatal: protocol error: bad pack header
#59 ERROR: executor failed running [/bin/sh -c PREFIX=/build /tmp/install/install.sh shfmt]: exit code: 128

Updated; moved renaming the default profile to a separate commit 👍 PTAL