New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker exposes dmesg to containers by default #37897

Closed
thejh opened this Issue Sep 21, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@thejh

thejh commented Sep 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@justincormack

justincormack Sep 27, 2018

Contributor

Thanks for the report, this does seem reasonable.

Contributor

justincormack commented Sep 27, 2018

Thanks for the report, this does seem reasonable.

@justincormack

This comment has been minimized.

Show comment
Hide comment
@justincormack

justincormack Sep 27, 2018

Contributor

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?

Contributor

justincormack commented Sep 27, 2018

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 added a commit to justincormack/docker that referenced this issue Sep 27, 2018

Move the syslog syscall to be gated by CAP_SYS_ADMIN or CAP_SYSLOG
This call is what is used to implement `dmesg` to get kernel messages
about the host. This can leak substantial information about the host.
It is normally available to unprivileged users on the host, unless
the sysctl `kernel.dmesg_restrict = 1` is set, but this is not set
by standard on the majority of distributions. Blocking this to restrict
leaks about the configuration seems correct.

Fix moby#37897

See also https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation-bug-in-linux.html

Signed-off-by: Justin Cormack <justin.cormack@docker.com>
@justincormack

This comment has been minimized.

Show comment
Hide comment
@justincormack

justincormack Sep 27, 2018

Contributor

PR in #37929

Contributor

justincormack commented Sep 27, 2018

PR in #37929

thaJeztah added a commit to thaJeztah/docker that referenced this issue Oct 2, 2018

Move the syslog syscall to be gated by CAP_SYS_ADMIN or CAP_SYSLOG
This call is what is used to implement `dmesg` to get kernel messages
about the host. This can leak substantial information about the host.
It is normally available to unprivileged users on the host, unless
the sysctl `kernel.dmesg_restrict = 1` is set, but this is not set
by standard on the majority of distributions. Blocking this to restrict
leaks about the configuration seems correct.

Fix moby#37897

See also https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation-bug-in-linux.html

Signed-off-by: Justin Cormack <justin.cormack@docker.com>
(cherry picked from commit ccd22ff)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment