Red Hat Bugzilla – Bug 1360634
CVE-2016-6349 oci-register-machine: information exposure for docker containers
Last modified: 2016-10-27 11:35:27 EDT
Once docker containers register themselves to systemd-machined by oci-register-machine, any unprivileged user could run machinectl to list every single container running in the host even if the containers do not belong to this user (including containers belong to the root user), and access sensitive information associated with any individual container including its internal IP address, OS version, running processes, and file path for its rootfs. $ machinectl status cc8d10c7b9892b75843d200d54d34a3a cc8d10c7b9892b75843d200d54d34a3a(63633864313063376239383932623735) Since: Mon 2016-07-25 17:55:36 UTC; 34s ago Leader: 43494 (sleep) Service: docker; class container Root: /var/mnt/overlay/overlay/0429684e3da515ae4f11b8514c7b20f759613 Address: 172.17.0.2 fe80::42:acff:fe11:2 OS: Red Hat Enterprise Linux Server 7.2 (Maipo) Unit: docker-cc8d10c7b9892b75843d200d54d34a3a9435fe0f65527c254ebfd2d └─43494 sleep 3000 CVE request: http://seclists.org/oss-sec/2016/q3/156
Acknowledgments: Name: CAI Qian (Red Hat)
Created systemd tracking bugs for this issue: Affects: fedora-all [bug 1360635]
As discussed elsewhere: This isn't really a security issue, for a couple of reasons: - machine registration is only accessible to privileged clients. - Read-only access to the the list of available machines and their properties is available for unprivileged clients, but this shouldn't be much of a problem. After all on UNIX/Linux unprivileged users generally get access to the process tree, which certainly carries substantially more relevant information than just the list of machines which group these processes. - Access is controlled via the dbus policy, and thus subject to dbus policies. The above is simply the default policy, and if more restrictive policy are required it's a simple matter of putting together the right dus XML. Thus, I believe the issue at hend is without merit and should simply be closed.
(In reply to Lennart Poettering from comment #3) > As discussed elsewhere: > > This isn't really a security issue, for a couple of reasons: > > - machine registration is only accessible to privileged clients. > > - Read-only access to the the list of available machines and their > properties is available for unprivileged clients, but this shouldn't be much > of a problem. After all on UNIX/Linux unprivileged users generally get > access to the process tree, which certainly carries substantially more > relevant information than just the list of machines which group these > processes. There are users use things like gresecurity/pax kernel patches to restrict process tree only to its user or group. > > - Access is controlled via the dbus policy, and thus subject to dbus > policies. The above is simply the default policy, and if more restrictive > policy are required it's a simple matter of putting together the right dus > XML. Right, it is up to oci-register-machine developers if they would like to pursue that route. I personally agree this is a clean solution. > > Thus, I believe the issue at hend is without merit and should simply be > closed. I suggest leave as it is. The ball is now in oci-register-machine developers’ court to at least give users a choice between security and usability as highlighted in the children bugs if put a restrict dbus policy is too heavy weight a solution for them to pursue.
the grsecurity/pax stuff is not in the upstream kernel. Have you filed a CVE against the upstream kernel because of that, too?
Not yet. I guess I could especially in the DevOps context. There are lots of things not consider security in the past and should be considered now.