Bug 1360634 (CVE-2016-6349)

Summary: CVE-2016-6349 oci-register-machine: information exposure for docker containers
Product: [Other] Security Response Reporter: Martin Prpič <mprpic>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: dkholia, johannbg, lnykryn, msekleta, muadda, qcai, ssahani, s, systemd-maint-list, systemd-maint, tjay
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-13 10:15:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1359809, 1360635, 1366337, 1366402    
Bug Blocks: 1360636    

Description Martin Prpič 2016-07-27 08:21:19 UTC
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

Comment 1 Martin Prpič 2016-07-27 08:21:32 UTC
Acknowledgments:

Name: CAI Qian (Red Hat)

Comment 2 Martin Prpič 2016-07-27 08:21:52 UTC
Created systemd tracking bugs for this issue:

Affects: fedora-all [bug 1360635]

Comment 3 Lennart Poettering 2016-08-12 09:32:16 UTC
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.

Comment 4 Qian Cai 2016-08-12 12:16:34 UTC
(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.

Comment 5 Lennart Poettering 2016-08-16 10:45:13 UTC
the grsecurity/pax stuff is not in the upstream kernel. Have you filed a CVE against the upstream kernel because of that, too?

Comment 6 Qian Cai 2016-08-16 12:33:55 UTC
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.