/proc/sched_debug Information Leak

[Jesse Hertz]

Description: Unprivileged containers can read from '/proc/sched_debug', a world-readable file within proc that contains a large amount of CFS and CPU scheduler information. This allows a trivial information leak which discloses what processes IDs and names are running in the host or other containers, as well as cgroup information which can disclose container names and other details. This effectively breaks the expected PID Namespace isolation.

Reproduction: Inside a default and unprivileged LXC container, run the command `cat /proc/sched_debug`. Note that information is displayed about processes running on the host, as well as inside other containers.

Sample output includes:
task PID tree-key switches prio exec-runtime sum-exec sum-sleep
----------------------------------------------------------------------------------------------------------
      kthreadd 2 319429235.224770 9339 120 319429235.224770 753.267075 1067018909.484918 0 /
     rcu_sched 7 319489137.064234 18896675 120 319489137.064234 170125.420028 1066508074.968528 0 /
       rcuos/5 13 319218638.012762 192 120 319218638.012762 0.896416 1065991450.159691 0 /
  .... SNIP .... .... SNIP ....
         acpid 1813 57932.203222 1676704 120 57932.203222 114395.580999 1067170248.528885 0 /autogroup-222
            sh 2273 113050772.150884 42 120 113050772.150884 0.754525 1066111947.155906 0 /user/1000.user/c1.session
          bash 2276 113052316.082339 788 120 113052316.082339 137.826052 1066155735.798643 0 /user/1000.user/c1.session
wpa_supplicant 2319 113098971.410443 119765 120 113098971.410443 6903.885769 1067229349.942336 0 /user/1000.user/c1.session
            sh 2426 113050772.151956 43 120 113050772.151956 2.035147 1066012436.338286 0 /user/1000.user/c1.session
         urxvt 2440 113098872.794317 606323 120 113098872.794317 28198.224898 1067122648.025421 0 /user/1000.user/c1.session
   dbus-daemon 2664 113092371.341763 6155 109 113092371.341763 432.939147 1066723733.656385 0 /user/1000.user/c1.session
      dio/dm-2 2695 20657.783903 2 100 20657.783903 0.007240 0.002253 0 /
Chrome_FileThre 3286 31903985.081343 213744 120 31903985.081343 14398.389541 1065335604.938435 0 /lxc/chrome

Recommendation: In the short term, modify the base LXC AppArmor profile to
block access to this file. In the long term, this procfs interface should be rewritten to be namespace aware and possibly restricted to root-only users. If AppArmor is not in use, end-users could recompile their kernel to have CONFIG_SCHED_DEBUG disabled.

#####

About NCC:
NCC Group is a security consulting company that performs all manner of
security testing and has a strong desire to help make the industry a
better, more resilient place. Because of this, when NCC Group
identifies vulnerabilities in a system they prefer to work closely with
vendors to create more secure systems. NCC Group strongly believes in
responsible disclosure, and has strict guidelines in place to ensure
that proper disclosure procedure is followed at all times. This serves
the dual purpose of allowing the vendor to safely secure the product or
system in question as well as allowing NCC Group to share cutting edge
research or advisories with the security community.

[Serge Hallyn (serge-hallyn)]

Hi,

thanks for filing this bug.

Below is my take on it.

From a security standpoint, unprivileged users on the host can also see the file. Were it sensitive enough to make it non-world-readable, then unprivileged containers would not be able to see the file. But since we trust unprivileged users to see it, unprivileged containers can also see it.

It was decided at a kernel summit way back in 2008 that "fooling containers into thinking they are not containers" is not a valid justificatoin for kernel patches. /proc in particular leaks quite a bit of host information into a container.

I can't think of any valid reason for containers to see this file, so an apparmor rule to hide it would be ok with me.

I'd also be ok with enhancing lxcfs to virtualize the file. That would be leave the container able to unmount the bind-mounted file and see the host contents, but might be useful to the container in certain cases, I suppose. Lastly, we could alter the kernel to always make that file non-world-readable. If it is actually security sensitive, then that would seem like the best approach.

[Jesse Hertz (jesse-hertz)]

I plan on discussing this in a whitepaper I'm finishing up now, so if you'd like any time to push out a patch, please let me know.

[Jesse Hertz (jesse-hertz)]

Just one last reminder re: disclosure (if any coordination is desired).

[Steve Beattie (sbeattie)]

Jesse, we don't need to coordinate a disclosure, so you are free to disclose this issue. Thanks for giving us advance notice!

[Steve Beattie (sbeattie)]

This was disclosed in the whitepaper referenced in https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/june/abusing-privileged-and-unprivileged-linux-containers/ (written by the reporter), so there's no need for this bug report to stay private.

[Stéphane Graber (stgraber)]

So options here are to apparmor block it, assuming that no common piece of software relies on it or to mask it with lxcfs (though that still allows access to user, so not necessarily ideal).

I'm a bit confused as to why this data is accessible to unprivileged users in the first place, wouldn't that also allow bypassing some of the /proc filtering modes?

[Stéphane Graber (stgraber)]

Closing as it's not really LXC's job to try and change that one.

These days we'd recommend distros to change default permissions or ideally get that changed at the kernel level. Short of that, we do have some documented recommendations in our production environment doc for LXD: https://linuxcontainers.org/lxd/docs/master/production-setup/