-
Notifications
You must be signed in to change notification settings - Fork 26
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
cgroup bind mount action in oci hook may increase security risk #84
Comments
If systemd would work without these other directories mounted, that would be find. The risk here is limited information leak. |
I try to just remount /sys/fs/cgroup(ro) and /sys/fs/cgroup/systemd(rw),systemd unit load seems fine. |
there maybe another big issue:if run --privileged,all cgroup subsystem becomes to rw,and oci hook remount them ro(system rw only),so they will be really ro but not rw as --privileged flag expected. |
@marszhe If you get a chance, open a PR to fix the cgroup mounting, to be just the creation of the directory. If systemd continues to work with this, that would be great. |
I use oci-systemd-hook to run systemd service in a container,found that in this container i can see all cgroup resource,including other normal container instance cgroup resource.
root@aaa:/# findmnt
|-/sys sysfs
| '-/sys/fs/cgroup tmpfs
| |-/sys/fs/cgroup/systemd cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/pids cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/net_cls,net_prio cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/freezer cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/devices cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/hugetlb cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/files cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/perf_event cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/memory cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/cpuset cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/blkio cgroup[/docker/abc]
| |
| |-/sys/fs/cgroup/cpu,cpuacct cgroup[/docker/abc]
| |
| '-/sys/fs/cgroup tmpfs
| |-/sys/fs/cgroup/systemd cgroup cgroup rw
| |-/sys/fs/cgroup/pids cgroup cgroup ro
| |-/sys/fs/cgroup/net_cls,net_prio cgroup cgroup ro
| |-/sys/fs/cgroup/freezer cgroup cgroup ro
| |-/sys/fs/cgroup/devices cgroup cgroup ro
| |-/sys/fs/cgroup/hugetlb cgroup cgroup ro
| |-/sys/fs/cgroup/files cgroup cgroup ro
| |-/sys/fs/cgroup/perf_event cgroup cgroup ro
| |-/sys/fs/cgroup/memory cgroup cgroup ro
| |-/sys/fs/cgroup/cpuset cgroup cgroup ro
| |-/sys/fs/cgroup/blkio cgroup cgroup ro
| `-/sys/fs/cgroup/cpu,cpuacct cgroup cgroup ro
root@aaa:/sys/fs/cgroup/cpu# ll docker
total 0
drwxr-xr-x. 6 root root 0 Dec 19 07:38 ./
drwxr-xr-x. 6 root root 0 Nov 17 12:25 ../
drwxr-xr-x. 2 root root 0 Dec 19 13:48 4641782f7b104132cef7ecd688bfe42aa2b5b6a84d5dea70c12165b3af294342/
drwxr-xr-x. 2 root root 0 Dec 19 13:44 4cbe4aebed912e0cbfbbe34e347483771fd5ae0a50ef5f39dda0bf1f7f4ba462/
drwxr-xr-x. 2 root root 0 Dec 19 08:38 9857caa62a8fcc07a2b133879d8e5d4cb4deac4c1f872f0682a82ff280f35211/
-rw-r--r--. 1 root root 0 Nov 17 12:27 cgroup.clone_children
--w--w--w-. 1 root root 0 Nov 17 12:27 cgroup.event_control
-rw-r--r--. 1 root root 0 Nov 17 12:27 cgroup.procs
-rw-r--r--. 1 root root 0 Nov 17 12:27 cpu.cfs_period_us
-rw-r--r--. 1 root root 0 Nov 17 12:27 cpu.cfs_quota_us
-rw-r--r--. 1 root root 0 Nov 17 12:27 cpu.rt_period_us
-rw-r--r--. 1 root root 0 Nov 17 12:27 cpu.rt_runtime_us
-rw-r--r--. 1 root root 0 Nov 17 12:27 cpu.shares
-r--r--r--. 1 root root 0 Nov 17 12:27 cpu.stat
-r--r--r--. 1 root root 0 Nov 17 12:27 cpuacct.stat
-rw-r--r--. 1 root root 0 Nov 17 12:27 cpuacct.usage
-r--r--r--. 1 root root 0 Nov 17 12:27 cpuacct.usage_percpu
drwxr-xr-x. 2 root root 0 Dec 19 07:43 d1f6317187a78e5a3f07b11a079f7d7d0e2583f4c60e6e166059c8265faa0f47/
-rw-r--r--. 1 root root 0 Nov 17 12:27 notify_on_release
-rw-r--r--. 1 root root 0 Nov 17 12:27 tasks
this means security risk here,so i'm curious about why we must mount cgroup again?
what is the systemd truly need?
should we just mount the control directory(/sys/fs/cgroup/systemd) but not do mount other cgroup subsystem?
or can we just use another way to run systemd with no risk?
@rhatdan @mrunalp @cgwalters @TomSweeneyRedHat
so much thanks
cc:@hqhq
The text was updated successfully, but these errors were encountered: