[systemd-devel] [PATCH 2/2] Run with a custom SMACK domain (label).

[Kok, Auke-jan H]

On Tue, Oct 8, 2013 at 3:29 PM, Schaufler, Casey
<casey.schaufler at intel.com> wrote:
>> -----Original Message-----
>> From: Lennart Poettering [mailto:lennart at poettering.net]
>> Sent: Tuesday, October 08, 2013 3:17 PM
>> To: Kok, Auke-jan H
>> Cc: Zbigniew Jędrzejewski-Szmek; Schaufler, Casey; systemd-devel
>> Subject: Re: [systemd-devel] [PATCH 2/2] Run with a custom SMACK domain
>> (label).
>>
>> On Mon, 07.10.13 10:30, Kok, Auke-jan H (auke-jan.h.kok at intel.com) wrote:
>>
>> > > Hi,
>> > > the patches look OK. I dont' have a system with smack support at
>> > > hand, but I tested them on Fedora, and didn't notice any adverse effects.
>> > > I you've tested them with smack, then they should be applied, imo.
>> >
>> > Thanks, I just applied them myself - I just wanted to give folks a bit
>> > of time to read and test - so thanks for doing so!
>>
>> Hmm, the patches as they are merged now try to mount the SMACK version
>> of /run and /dev/shm also in containers. Will this work?
>
> So long as the cgroup filesystem propagates the xattrs to and from the real
> filesystem it won't be a problem. If the cgroup filesystem is not doing that
> there will be a problem.
>
>>
>> So far (at least for SELinux) we tried to turn off all security layers in
>> containers, since the policies are not virtualized.
>
> I don't know what you mean by "virtualized" in this context.
>
>> Due to that it sounds more
>> appropriate not to mount these SMACK versions in a container. More
>> specifically, I'd like to remove the MNT_IN_CONTAINER flags from the lines
>> you just added?
>
> That does sound like the safest approach. I would be fine with that.
>
>>
>> Does that make sense to you?


yes, that makes sense. I'll include this in the patch that makes the
smack-specific mounts not throw errors since that touches these lines
as well.

Auke