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

[Stephen Smalley <sds@xxxxxxxxxxxxx>]

On 5/10/19 10:55 AM, Stephen Smalley wrote:
> 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.

Looks like someone added a type, genfscon, and allow rules for nsfs to 
the goldfish sepolicy,
$ grep -r nsfs device/generic/goldfish/sepolicy
device/generic/goldfish/sepolicy/common/genfs_contexts:genfscon nsfs / 
u:object_r:nsfs:s0
device/generic/goldfish/sepolicy/common/execns.te:allow execns nsfs:file 
{ open read };
device/generic/goldfish/sepolicy/common/vold.te:allow vold nsfs:file 
r_file_perms;
device/generic/goldfish/sepolicy/common/goldfish_setup.te:allow 
goldfish_setup nsfs:file r_file_perms;
device/generic/goldfish/sepolicy/common/file.te:type nsfs, fs_type;

Don't know if most of that ought to be moved over to system/sepolicy. 
Looks like execns is goldfish-specific 
(device/generic/goldfish/wifi/execns), as is goldfish_setup of course. 
At least the type declaration and genfscon statement probably should 
live in system/sepolicy.  And whether or not you keep it as a separate 
nsfs type or switch to proc for consistency/compatibility with older 
kernels/policies is up to you.  I guess the question is whether you 
want/need to allow nsfs access without allowing access to the generic 
proc type.