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

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

[Jeffrey Vander Stoep]

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

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

[Stephen Smalley]

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.

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

[Jeffrey Vander Stoep]

From: Stephen Smalley <sds@tycho.nsa.gov>
Date: Thu, May 9, 2019 at 2:17 PM
To: Jeffrey Vander Stoep, <selinux@vger.kernel.org>, 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.

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

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

On Thu, May 09, 2019 at 02:47:30PM -0700, Jeffrey Vander Stoep wrote:
> From: Stephen Smalley <sds@tycho.nsa.gov>
> Date: Thu, May 9, 2019 at 2:17 PM
> To: Jeffrey Vander Stoep, <selinux@vger.kernel.org>, 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.

# seinfo --genfs | grep nsfs
   genfscon nsfs /  sys.id:sys.role:fs.nsfs.fs:s0

Yes, i think this is a step backwards. In the past we got a nice list of objects that have no context associated when policy is loaded.
That list was removed. So sometimes its hard to determine whether something needs a genfscon if its not listen with `mount.

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Stephen Smalley]

On 5/10/19 3:12 AM, Dominick Grift wrote:
> On Thu, May 09, 2019 at 02:47:30PM -0700, Jeffrey Vander Stoep wrote:
>> From: Stephen Smalley <sds@tycho.nsa.gov>
>> Date: Thu, May 9, 2019 at 2:17 PM
>> To: Jeffrey Vander Stoep, <selinux@vger.kernel.org>, 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.
> 
> # seinfo --genfs | grep nsfs
>     genfscon nsfs /  sys.id:sys.role:fs.nsfs.fs:s0
> 
> Yes, i think this is a step backwards. In the past we got a nice list of objects that have no context associated when policy is loaded.
> That list was removed. So sometimes its hard to determine whether something needs a genfscon if its not listen with `mount.

So, to be specific, commit 2088d60e3b2f53d0c9590a0202eeff85b288b1eb 
("selinux: quiet the filesystem labeling behavior message") removed the 
logging of which filesystem labeling behavior was selected for each 
filesystem, and then the last remnant was dropped by commit 
270e8573145a26de924e2dc644596332d400445b ("selinux: Remove redundant 
check for unknown labeling behavior").  The second commit makes sense 
given the prior one, but perhaps we do need/want to retain some kind of 
log message when mounting a filesystem that is not configured for 
labeling (i.e. SECURITY_FS_USE_NONE)?  We could add back a log message 
just for that case without reverting the other changes.

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

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3785 bytes --]

On Fri, May 10, 2019 at 10:28:50AM -0400, Stephen Smalley wrote:
> On 5/10/19 3:12 AM, Dominick Grift wrote:
> > On Thu, May 09, 2019 at 02:47:30PM -0700, Jeffrey Vander Stoep wrote:
> > > From: Stephen Smalley <sds@tycho.nsa.gov>
> > > Date: Thu, May 9, 2019 at 2:17 PM
> > > To: Jeffrey Vander Stoep, <selinux@vger.kernel.org>, 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.
> > 
> > # seinfo --genfs | grep nsfs
> >     genfscon nsfs /  sys.id:sys.role:fs.nsfs.fs:s0
> > 
> > Yes, i think this is a step backwards. In the past we got a nice list of objects that have no context associated when policy is loaded.
> > That list was removed. So sometimes its hard to determine whether something needs a genfscon if its not listen with `mount.
> 
> So, to be specific, commit 2088d60e3b2f53d0c9590a0202eeff85b288b1eb
> ("selinux: quiet the filesystem labeling behavior message") removed the
> logging of which filesystem labeling behavior was selected for each
> filesystem, and then the last remnant was dropped by commit
> 270e8573145a26de924e2dc644596332d400445b ("selinux: Remove redundant check
> for unknown labeling behavior").  The second commit makes sense given the
> prior one, but perhaps we do need/want to retain some kind of log message
> when mounting a filesystem that is not configured for labeling (i.e.
> SECURITY_FS_USE_NONE)?  We could add back a log message just for that case
> without reverting the other changes.

I would appreciate that, yes.

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Stephen Smalley]

On 5/9/19 8:32 PM, Stephen Smalley wrote:
> On Thu, May 9, 2019, 5:49 PM Jeffrey Vander Stoep <jeffv@google.com 
> <mailto:jeffv@google.com>> wrote:
> 
>     From: Stephen Smalley <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>
>     Date: Thu, May 9, 2019 at 2:17 PM
>     To: Jeffrey Vander Stoep, <selinux@vger.kernel.org
>     <mailto:selinux@vger.kernel.org>>, 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.

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

[Stephen Smalley]

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@google.com 
>> <mailto:jeffv@google.com>> wrote:
>>
>>     From: Stephen Smalley <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>
>>     Date: Thu, May 9, 2019 at 2:17 PM
>>     To: Jeffrey Vander Stoep, <selinux@vger.kernel.org
>>     <mailto:selinux@vger.kernel.org>>, 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.

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

[Stephen Smalley]

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@google.com 
>>> <mailto:jeffv@google.com>> wrote:
>>>
>>>     From: Stephen Smalley <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>
>>>     Date: Thu, May 9, 2019 at 2:17 PM
>>>     To: Jeffrey Vander Stoep, <selinux@vger.kernel.org
>>>     <mailto:selinux@vger.kernel.org>>, 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.