On 1/17/19 11:15 AM, Tejun Heo wrote: > Hello, > > On Thu, Jan 17, 2019 at 10:01:23AM -0500, Daniel Walsh wrote: >> The above comment is correct. We want to be able to run a container >> where we hand it control over a limited subdir of the cgroups hierachy. >> We can currently do this and label the content correctly, but when >> subdirs of the directory get created by processes inside the container >> they do not get the correct label. For example we add a label like >> system_u:object_r:container_file_t:s0 to a directory but when the >> process inside of the container creates a fd within this directory the >> kernel says the label is the default label for cgroups >> system_u:object_r:cgroup_t:s0. This forces us to write looser policy >> that from an SELinux point of view allows a process within the container >> to write anywhere on the cgroup file system, rather then just the >> designated directories. > Can you please go into a bit more details on why the existing > cgroup delegation model isn't enough? > > Thanks. > If I label a container container_t:s0:c1,c2 by policy it can only write to container_file_t:s0:c1,c2. So the container engine sets up files and directories within the cgroup hierarchy with labels of container_file_t:s0:c1,c2. When the container writes to one of these directories, the kernel says the file is labeled cgroup_t:s0, and is denied by policy. In most/all other file systems that support labeling, the content of a directory gets the same label as the containing directory. So from an SELinux point of view, I would have expected the kernel to label the new file as container_file_t:s0:c1,c2 and everything would work securely. But cgroups does not work correctly so we need to add a rule that says container_t:s0:c1,c2 can write files labeles cgroup_t:s0 which means it can write anywhere on /sys/fs/cgroup. This is from a MAC Point of view. I don't care if other security measure might control this, I want to have security in depth and have MAC Control it.
