On 12/07/2016 10:47 AM, Stephen Smalley wrote:
> On 12/07/2016 10:30 AM, Stephen Smalley wrote:
>> On 12/06/2016 07:19 PM, Paul Moore wrote:
>>> On Tue, Dec 6, 2016 at 3:31 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
>>>> On 12/06/2016 03:04 PM, Daniel J Walsh wrote:
>>>>> Currently in SELinux and UserNamespace can not be enabled with
>>>>> Docker/runc at the same time.
>>>>>
>>>>> Runc mounts tmpfs directories with
>>>>> --context="system_u:object_r:container_file_t:s0:c1,c2" type labels
>>>>> but the following patch blocks the use of context mounts when using user
>>>>> namespace.
>>>>>
>>>>> http://kernel.suse.com/cgit/kernel/commit/?id=aad82892af261b9903cc11c55be3ecf5f0b0b4f8
>>>>>
>>>>> User Namespace has to be established before tmpfs are mounted so we are
>>>>> unable to mount a
>>>>> tmpfs with a context=flag and UserNamespace enabled.
>>>>>
>>>>> Controlling the ability to change the label of a mounted file systemd
>>>>> should be a MAC decision not a DAC,
>>>>> or UserNamespace. Setting the SELinux labels on an object like a file
>>>>> system mount point
>>>>> should be controlled by SELinux. SELinux should check if the label of
>>>>> the process doing the
>>>>> mount is able to relabel from the label of the mount point, and labelto
>>>>> the specified label.
>>>>>
>>>>> SELinux does this for privileged processes (running with SYS_ADMIN) so
>>>>> use namespace should not be
>>>>> any different. Also the process doing the mount would be allowed by DAC
>>>>> to set the label of the tmpfs after
>>>>> it is mounted (As long as SELinux allowed).
>>>>>
>>>>> There is no security difference between:
>>>>>
>>>>> mount -o tmpfs context="foobar" none /dev
>>>>>
>>>>>
>>>>> And
>>>>>
>>>>> mount -o tmpfs none /dev
>>>>>
>>>>> chcon foobar -R /dev
>>>>>
>>>>>
>>>>> The second would not be blocked by usernamespace.
>>>>>
>>>>> Bottom line this patch should be reverted so container runtimes like
>>>>> docker can use both User Namespace
>>>>> and SELinux at the same time.
>>>> I doubt we want to revert it entirely. Looks like Smack has an explicit
>>>> exemption for tmpfs/ramfs (and sysfs, but it wouldn't really make sense
>>>> to do it there). We could do something similar.
>>> Yes, I still think the restriction makes sense for persistent
>>> filesystems, but for things like tmpfs it does seem silly.
>> Looking further at this, the set of filesystems that presently allow
>> userns mounting are mqueue, tmpfs, cgroup/cgroup2, sysfs, ramfs, proc,
>> and devpts. I could see allowing context mounts for mqueue, tmpfs,
>> ramfs, and devpts within the user namespace. For cgroup/cgroup2, sysfs
>> and proc we don't want the process to be able to override the
>> policy-defined labels. Make sense?
> Sorry, never mind about mqueue - unless the process is also in its own
> IPC namespace, that could allow it to effectively relabel existing
> mqueues. So only tmpfs, ramfs, and devpts seem to be safe in this regard.
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
>
>
That works for me. The mqueue one we might have to visit later. I
think docker and
user namespace with mqueue is currently a problem.
_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
