Re: [PATCH 0/3] Allow initializing the kernfs node's secctx based on its parent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux