dockerd: add --print-default-{seccomp,apparmor} profile

[AkihiroSuda]

Signed-off-by: Akihiro Suda akihiro.suda.cz@hco.ntt.co.jp

- What I did
added --print-default-{seccomp,apparmor} profile to dockerd, so that the user can inspect the default configuration

Fix #33060

- How to verify it

$ dockerd --print-default-seccomp-profile
{
        "defaultAction": "SCMP_ACT_ERRNO",
        "archMap": [
                {
                        "architecture": "SCMP_ARCH_X86_64",
                        "subArchitectures": [
                                "SCMP_ARCH_X86",
                                "SCMP_ARCH_X32"
                        ]
                },
...
                {
                        "names": [
                                "syslog"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "args": [],
                        "comment": "",
                        "includes": {
                                "caps": [
                                        "CAP_SYSLOG"
                                ]
                        },
                        "excludes": {}
                }
        ]
}

$ dockerd --print-default-apparmor-profile


#include <tunables/global>


profile docker-default flags=(attach_disconnected,mediate_deleted) {

  #include <abstractions/base>


  network,
  capability,
  file,
  umount,


  signal (receive) peer=unconfined
,

  signal (send,receive) peer=docker-default,


  deny @{PROC}/* w,   # deny write for all files directly in /proc (not in a subdir)
  # deny write to files not in /proc/<number>/** or /proc/sys/**
  deny @{PROC}/{[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9]*}/** w,
  deny @{PROC}/sys/[^k]** w,  # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel)
  deny @{PROC}/sys/kernel/{?,??,[^s][^h][^m]**} w,  # deny everything except shm* in /proc/sys/kernel/
  deny @{PROC}/sysrq-trigger rwklx,
  deny @{PROC}/kcore rwklx,

  deny mount,

  deny /sys/[^f]*/** wklx,
  deny /sys/f[^s]*/** wklx,
  deny /sys/fs/[^c]*/** wklx,
  deny /sys/fs/c[^g]*/** wklx,
  deny /sys/fs/cg[^r]*/** wklx,
  deny /sys/firmware/** rwklx,
  deny /sys/kernel/security/** rwklx,


  # suppress ptrace denials when using 'docker ps' or using 'ps' inside a container
  ptrace (trace,read,tracedby,readby) peer=docker-default,

}

- Description for the changelog
dockerd: add --dump-default-{seccomp,apparmor} profile

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

🐧

[AkihiroSuda]

@justincormack @thaJeztah PTAL?

[AkihiroSuda]

@thaJeztah @justincormack @cpuguy83 PTAL?

[thaJeztah]

Sorry, thought I left a comment already, but apparently forgot 😞

Wondering if we should add flags for these, or if we should log the profiles when (re)loading the configuration; same as I did in #36019 (8378dcf), that way both systemctl service reload docker (or (I think)) sending a SIGHUP would print the active configuration and profiles in the logs

[thaJeztah]

Wondering if we should add flags for these, or if we should log the profiles when (re)loading the configuration

Guess it's slightly more complicate for the AppArmor profile to log it (the seccomp profile is JSON so easier to log) 🤔

[AkihiroSuda]

Wondering if we should add flags for these, or if we should log the profiles when (re)loading the configuration; same as I did in #36019 (8378dcf), that way both systemctl service reload docker (or (I think)) sending a SIGHUP would print the active configuration and profiles in the logs

The latter approach almost doesn't work for scripting

[thaJeztah]

The latter approach almost doesn't work for scripting

True; basically trying to prevent adding a lot of flags if there's no real need; reading the related ticket; the main reason is to have the possibility to audit what's loaded. I'm not sure if scripting is involved in that, or if that's manually reading the profile (having the profile logged on startup, reload / SIGHUP / SIGUSR1) would still work for that.

If a file is needed with the profiles, we could consider doing the same as we do for the stack dumps, and write it to a file

moby/daemon/debugtrap_unix.go

Lines 18 to 25 in 8e610b2

	for range c {
	path, err := stackdump.DumpStacks(root)
	if err != nil {
	logrus.WithError(err).Error("failed to write goroutines dump")
	} else {
	logrus.Infof("goroutine stacks written to %s", path)
	}
	}

[AkihiroSuda]

the main reason is to have the possibility to audit what's loaded

No, the main reason (to me) is to facilitate people to write custom profiles by modifying the default template: docker/for-linux#788

[cpuguy83]

This seems fine, but an API endpoint (e.g. perhaps something like GET /debug/profiles/apparmor may be more helpful, especially for cases like docker desktop.

[AkihiroSuda]

@thaJeztah API endpoint SGTY?

[AkihiroSuda]

ping @thaJeztah

[AkihiroSuda]

@thaJeztah WDYT about #39923 (comment) ?

Also curious whether this should be under /system or /debug. I think this feature is not only for debugging, and can be a path like /system/default_profiles/{apparmor,seccomp}

[mrueg]

@cpuguy83 this would be nice to have in v21.x

[thaJeztah]

Given that these cannot be combined, should we have a single flag that takes an option? Something like;

--print-default-profile=<seccomp|apparmor>

or (removing -default from the flag name)

--print-profile=<seccomp|apparmor>

[thaJeztah]

Could also be the reverse, and make it --print-defaults (so that we could, e.g. use it to print other defaults that are configured, such as dns, ulimit, etc)

[thaJeztah]

As to

API endpoint SGTY?

I think that would be useful to have (but will be a bigger change obviously); not sure if that endpoint should always print everything, or have options to provide more granular information (to avoid getting in the same situation as we have with the /info endpoint returning far too much information for most uses)

[AkihiroSuda]

Should we implement --print-profile=<seccomp|apparmor> first in this PR, and then revisit the REST API in a follow-up PR?

[thaJeztah]

@AkihiroSuda works for me; I just left another comment, thinking about naming it --print-default (which could then be used more-widely perhaps); WDYT? (suggestions/input welcome)

[AkihiroSuda]

--print-default SGTM

[thaJeztah]

@AkihiroSuda I just recalled this PR was still pending; looks like it needs a rebase 😬 - could you have a look?

[AkihiroSuda]

We may have multiple built-in profiles (#42441), so this PR will probably needs to be redesigned