Description of problem: This bugzilla maps the https://bugzilla.redhat.com/show_bug.cgi?id=1094188 issue on newer docker-io-0.10 on real hardware. Docker gives access to host /sys. This is expected as some apps requires /sys and one would expect it's protected (in --privileged=False). Well, is it? This time I tried `echo mem > /sys/power/state` which (unlike on older docker) succeeded and suspended the whole laptop. I guess this is not required from containerized machine to be able to do? Additionally I tried modifying the cpu frequence: echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq passes (which is IMO improper behavior) Last but not least I tried `poweroff -f`, but "sadly" it just stopped the container without powering off the host machine. Version-Release number of selected component (if applicable): docker-io-0.10.0-2.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. Play with /sys Actual results: container is able to interact/suspend/modify the underlying host machine. Expected results: docker should prevent these operations.
Hello guys, the RHEL version of docker mounts /sys as read-only, which fixes the problem of interacting with underlying machine. Question is, whether an attacker can't abuse some /sys information for potential attack. Anyway that's not the purpose of this bugzilla.
docker-io-0.11.1-2.fc20 mounts /sys as read/only.