FEATURE REQUEST
Description
Currently, the dockerd binary always runs containers as docker-default if AppArmor is enabled on the host.
|
if apparmor.IsEnabled() { |
|
var appArmorProfile string |
|
if c.AppArmorProfile != "" { |
|
appArmorProfile = c.AppArmorProfile |
|
} else if c.HostConfig.Privileged { |
|
// `docker exec --privileged` does not currently disable AppArmor |
|
// profiles. Privileged configuration of the container is inherited |
|
appArmorProfile = unconfinedAppArmorProfile |
|
} else { |
|
appArmorProfile = defaultAppArmorProfile |
|
} |
|
|
|
if appArmorProfile == defaultAppArmorProfile { |
|
// Unattended upgrades and other fun services can unload AppArmor |
|
// profiles inadvertently. Since we cannot store our profile in |
|
// /etc/apparmor.d, nor can we practically add other ways of |
|
// telling the system to keep our profile loaded, in order to make |
|
// sure that we keep the default profile enabled we dynamically |
|
// reload it if necessary. |
|
if err := ensureDefaultAppArmorProfile(); err != nil { |
|
return err |
|
} |
|
} |
|
p.ApparmorProfile = appArmorProfile |
|
} |
https://github.com/opencontainers/runc/blob/44f221e2fce70dd6a75e7d67e9bdde36706aef79/libcontainer/apparmor/apparmor.go#L15-L21
As an administrator, I'd like to use AppArmor to restrict dockerd from performing certain operations on a portion of my fleet (developer machines). However, since dockerd always attempts to apply a custom profile (by writing to /proc/self/attr/exec), runc can always get around my restrictions by running containers as unconstrained. If I restrict writes to /proc/self/attr/exec, then runc will always fail to start containers.
Currently, I have two options:
- Compile dockerd myself with build tags and distributing different packages to different hosts (different docker packages for developer machines vs. servers)
- Hide /sys/kernel/security/apparmor from dockerd (nice and hacky).
As an alternative, I'd like to send a PR that adds a dockerd flag to disable AppArmor integration (similar to --selinux-enabled). Does this sound reasonable?
https://docs.docker.com/engine/reference/commandline/dockerd/
/cc @cyphar
FEATURE REQUEST
Description
Currently, the dockerd binary always runs containers as docker-default if AppArmor is enabled on the host.
moby/daemon/exec_linux.go
Lines 30 to 54 in b4cb377
https://github.com/opencontainers/runc/blob/44f221e2fce70dd6a75e7d67e9bdde36706aef79/libcontainer/apparmor/apparmor.go#L15-L21
As an administrator, I'd like to use AppArmor to restrict dockerd from performing certain operations on a portion of my fleet (developer machines). However, since dockerd always attempts to apply a custom profile (by writing to /proc/self/attr/exec), runc can always get around my restrictions by running containers as unconstrained. If I restrict writes to /proc/self/attr/exec, then runc will always fail to start containers.
Currently, I have two options:
As an alternative, I'd like to send a PR that adds a dockerd flag to disable AppArmor integration (similar to --selinux-enabled). Does this sound reasonable?
https://docs.docker.com/engine/reference/commandline/dockerd/
/cc @cyphar