Description
A privileged container confined to an apparmor profile specified with --security-opt apparmor=profile-name is run as "unconfined" after restarting the container.
The profile is only used when first starting the container with docker run, but stopping the container and starting it with docker start starts it as unconfined (auto_restart works, too).
Steps to reproduce the issue:
- (optional, gives proof in audit.log) Build container with a program that changes apparmor hat
- Start container with
docker run --privileged --security-opt apparmor=docker-default, note container id and stop it
- Start container again with docker start
Another way, same results:
- Set restart_policy for container with apparmor profile
- let container auto-restart, for example reboot
- Processes in containers are now unconfined
Describe the results you received:
First of all, aa-status does not show the processes in the container to be in enforce mode. They are missing in aa-status output completely.
Secondly, audit.log shows the following log entry, coming from the "unconfined" profile if you try to change hat:
type=SYSCALL msg=audit(1540385552.452:1913897): arch=c000003e syscall=1 success=no exit=-2 a0=32 a1=30da220 a2=24 a3=7 items=0 ppid=91225 pid=92216 auid=4294967295 uid=377118 gid=65534 euid=377118 suid=377118 fsuid=377118 egid=65534 sgid=65534 fsgid=65534 tty=(none) ses=4294967295 comm="php-fpm" exe="/opt/lima-php/5.6/sbin/php-fpm" key=(null)
type=UNKNOWN[1327] msg=audit(1540385552.452:1913897): proctitle=7068702D66706D3A206D61737465722070726F6365737320282F6F70742F6C696D612D7068702F352E362F6574632F7068702D66706D2E636F6E6629
type=AVC msg=audit(1540385552.452:1913898): apparmor="DENIED" operation="change_profile" info="label not found" error=-2 profile="unconfined" name="unconfined//webdefault" pid=92217 comm="php-fpm"
Describe the results you expected:
aa-status showing the processes under "processes are in enforce mode"- AppArmor changing the hat without error message in audit.log
Additional information you deem important (e.g. issue happens only occasionally):
The bug only presents itself in privileged containers.
When you don't have code that changes apparmor hat, I don't see how the bug surfaces at all, unless you watch aa-status. As the container runs unconfined, you'll never really see any problems or hints of a problem.
Output of docker version:
Client:
Version: 18.06.1-ce
API version: 1.38
Go version: go1.10.3
Git commit: e68fc7a
Built: Tue Aug 21 17:20:43 2018
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 18.06.1-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.3
Git commit: e68fc7a
Built: Tue Aug 21 17:28:38 2018
OS/Arch: linux/amd64
Experimental: false
Output of docker info:
Containers: 43
Running: 1
Paused: 0
Stopped: 42
Images: 18
Server Version: 18.06.1-ce
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 296
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-116-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 11.73GiB
Name: qgmdrp7q
ID: XWH2:JCXJ:GQBQ:MZUK:2YGE:3NPY:W6FG:GIFJ:7O5F:IDNI:JQU6:FJSY
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
Additional environment details (AWS, VirtualBox, physical, etc.):
Ubuntu trusty, KVM virtual machine
Description
A privileged container confined to an apparmor profile specified with
--security-opt apparmor=profile-nameis run as "unconfined" after restarting the container.The profile is only used when first starting the container with
docker run, but stopping the container and starting it withdocker startstarts it as unconfined (auto_restart works, too).Steps to reproduce the issue:
docker run --privileged --security-opt apparmor=docker-default, note container id and stop itAnother way, same results:
Describe the results you received:
First of all,
aa-statusdoes not show the processes in the container to be in enforce mode. They are missing inaa-statusoutput completely.Secondly, audit.log shows the following log entry, coming from the "unconfined" profile if you try to change hat:
Describe the results you expected:
aa-statusshowing the processes under "processes are in enforce mode"Additional information you deem important (e.g. issue happens only occasionally):
The bug only presents itself in privileged containers.
When you don't have code that changes apparmor hat, I don't see how the bug surfaces at all, unless you watch aa-status. As the container runs unconfined, you'll never really see any problems or hints of a problem.
Output of
docker version:Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.):
Ubuntu trusty, KVM virtual machine