Re: Mislabeled /proc/<pid>/ns/mnt files?

[Stephen Smalley <sds@tycho.nsa.gov>]

On 5/9/19 3:56 PM, Jeffrey Vander Stoep wrote:
> I expected files here would have the process's context, but they
> don't. The files are actually all symlinks so it's entirely possible
> that the they shouldn't have the process's context. If that's the
> case, how can I provide different labels for them? Neither "proc" nor
> "unlabeled" are appropriate.
> 
> On a device with a 3.18 kernel they have the "proc" context:
> sailfish:/ # ls -LZ1 /proc/1/ns
> u:object_r:proc:s0 mnt
> u:object_r:proc:s0 net
> 
> On a device with the 4.9 kernel the have the "unlabeled" context:
> blueline:/ # ls -LZ1 /proc/1/ns
> u:object_r:unlabeled:s0 cgroup
> u:object_r:unlabeled:s0 mnt
> u:object_r:unlabeled:s0 net

First, ls -L dereferences symlinks so you are going to get the context 
of the object referenced by the symlink, not the context of the symlink 
itself.

Second, the task context is only assigned to proc inodes created via 
proc_pid_make_inode(), which has never been the case of /proc/pid/ns 
inodes - those have their own implementations and operations.

Third, /proc/pid/ns migrated from proc to its own pseudo filesystem, 
nsfs, which requires a corresponding fs_use or genfscon rule in policy 
or they will be unlabeled.  refpolicy has a genfscon rule. Confusingly 
there appears to be both in Fedora policy, a fs_use_task and a genfscon 
rule, and it appears that fs_use_task is being applied here.  I don't 
know why or what exactly that means.  It won't be the task context for 
the task associated with that /proc/pid directory but instead would be 
whichever task context instantiates the inode.