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

[Stephen Smalley <sds@xxxxxxxxxxxxx>]

On 5/10/19 8:38 AM, Stephen Smalley wrote:
> On 5/9/19 8:32 PM, Stephen Smalley wrote:
> > On Thu, May 9, 2019, 5:49 PM Jeffrey Vander Stoep <jeffv@xxxxxxxxxx 
> > <mailto:jeffv@xxxxxxxxxx>> wrote:
> >
> >     From: Stephen Smalley <sds@xxxxxxxxxxxxx <mailto:sds@xxxxxxxxxxxxx>>
> >     Date: Thu, May 9, 2019 at 2:17 PM
> >     To: Jeffrey Vander Stoep, <selinux@xxxxxxxxxxxxxxx
> >     <mailto:selinux@xxxxxxxxxxxxxxx>>, Joel Galenson,
> >     Petr Lautrbach
> >
> >      > 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.
> >
> >     I'm seeing a denial on the object not the symlink, so -L is what I 
> > want.
> >
> >      >
> >      > 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.
> >      >
> >
> >     So, how do I label these files in genfs_contexts?
> >
> >     "mount | grep nsfs" returns nothing.
> >
> >
> > Just a single entry for the nsfs / should suffice if using genfscon. 
> > That will apply a single label to all nsfs inodes. If you need to 
> > distinguish than fs_use_task might work better but you'd have to check 
> > when these inodes get instantiated; they are not per task but rather 
> > per namespace iiuc. See 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e149ed2b805fefdccf7ccdfc19eca22fdd4514ac 
>
> Actually, looking at the nsfs code, it looks like the inode gets 
> allocated when the link is first followed, so fs_use_task nsfs would be 
> misleading - it would get the context of whatever task first followed 
> the link, not the associated task for the /proc/pid directory.  And 
> really, these objects are not per-process state; they are per-namespace 
> (note that ls -Li shows the same inode number for anything sharing that 
> namespace). genfscon is the only thing that makes sense for labeling in 
> that case.  Arguably, namespaces should be labeled from their creating 
> process and these pseudo files should inherit that label but that would 
> require kernel changes to label namespaces and propagate those labels.
>
> Red Hat folks, why do you have both fs_use_task nsfs and genfscon nsfs 
> in your policy?  I think the fs_use_task is wrong here; probably was an 
> attempt to label the targets of the /proc/pid/ns links with the same 
> label as the other /proc/pid nodes but that isn't right and won't work; 
> try ls -LZ /proc/1/ns for example and contrast with ls -lZ /proc/1/ns.

From a compatibility POV, it would probably be best to assign nsfs the 
same context as proc via genfscon so that policy that worked on v3.18 
and earlier will continue working under later kernels, unless there is 
some real reason to distinguish these accesses.