docker exposes dmesg to containers by default

[thejh]

Description

Docker exposes the dmesg kernel log to containers by default, unless the host distribution prevents non-root from accessing dmesg. This is a potential security risk and leaks host state into the container; the dmesg log can contain things like kernel register dumps, which can aid in exploiting the kernel, and metadata about other processes running on the system. Therefore, I believe that docker should not allow containers to access dmesg, even if the distribution permits it for unprivileged userspace processes.

I am filing a public bug, rather than sending a private security report, because I believe that this counts as a security hardening suggestion, not a security bug.

Steps to reproduce the issue:

1. Installed docker on Ubuntu 18.04.
2. Launched a container with docker run -it ubuntu.
3. Ran dmesg inside the container.

Describe the results you received:
dmesg prints the kernel's dmesg buffer, including things like kernel register dumps. It achieves this by using the syslog() syscall (not to be confused with the syslog() library function!).

Describe the results you expected:
dmesg should fail. Specifically, the default seccomp profile should not permit the syslog() syscall.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

root@ubuntu-18-04-vm:~# 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:24:51 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:23:15 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker info:

root@ubuntu-18-04-vm:~# docker info
Containers: 2
 Running: 1
 Paused: 0
 Stopped: 1
Images: 2
Server Version: 18.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: 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.15.0-34-generic
Operating System: Ubuntu 18.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.852GiB
Name: ubuntu-18-04-vm
ID: KJ3G:LYXZ:5DX6:7BKE:DVMF:PFPX:RSOZ:S5B3:2V3I:L5O3:LXFF:Y6X4
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.):

Running in a KVM guest.

[justincormack]

Thanks for the report, this does seem reasonable.

[justincormack]

Hmm, ok so I tested this on Docker for Mac, and I get permission denied unless I use docker run -it --cap-add syslog alpine dmesg. It turns out we set the sysctl kernel.dmesg_restrict = 1 which I had forgotten about. I wonder if we should recommend this host setting instead? Maybe the seccomp policy is better though?

[justincormack]

PR in #37929