Re: Labeling nsfs filesystem

["Christopher J. PeBenito" <cpebenito@tresys.com>]

On 1/8/2016 9:13 AM, Stephen Smalley wrote:
> On 01/08/2016 08:00 AM, Christopher J. PeBenito wrote:
>> On 1/7/2016 4:19 PM, Stephen Smalley wrote:
>>> On 01/07/2016 03:36 PM, Nicolas Iooss wrote:
>>>> Hello,
>>>>
>>>> Since Linux 3.19 targets of /proc/PID/ns/* symlinks have lived in a fs
>>>> separated from /proc, named nsfs [1].  These targets are used to enter
>>>> the namespace of another process by using setns() syscall [2].  On old
>>>> kernels, they were labeled with procfs default type (for example
>>>> "getfilecon /proc/self/ns/uts" returned system_u:object_r:proc_t:s0).
>>>> When using a recent kernel with a policy without nsfs support, the
>>>> inodes are not labeled, as reported for example in Fedora bug #1234757
>>>> [3].  As I encounter this issue on my systems, I asked yesterday on the
>>>> refpolicy ML how nsfs inodes should be labeled [4].
>>>>
>>>> After digging a little bit about the possibilities, here is a
>>>> summary of
>>>> the options I have considered so far.
>>>>
>>>> Option 1: define a new type to label nsfs inodes, nsfs_t.  This
>>>> works as
>>>> expected (c.f. [5] for more details).
[...]
>>> Only option 1 makes sense to me.
>>
>> I don't understand the usage of nsfs which makes this confusing, but why
>> doesn't option 3 make sense?  Since it's under a particular /proc/pid
>> entry, doesn't it make sense to label the object as the domain's type?
> 
> The symlink is under a particular /proc/pid directory, but the target is
> per-namespace, not per-process.

In that case, I agree with the genfscon approach.  I originally thought
it was per-process.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com