SELinux Archive on lore.kernel.org
 help / Atom feed
* Mislabeled /proc/<pid>/ns/mnt files?
@ 2019-05-09 19:56 Jeffrey Vander Stoep
  2019-05-09 21:11 ` Stephen Smalley
  0 siblings, 1 reply; 9+ messages in thread
From: Jeffrey Vander Stoep @ 2019-05-09 19:56 UTC (permalink / raw)
  To: selinux, Joel Galenson

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Mislabeled /proc/<pid>/ns/mnt files?
  2019-05-09 19:56 Mislabeled /proc/<pid>/ns/mnt files? Jeffrey Vander Stoep
@ 2019-05-09 21:11 ` Stephen Smalley
  2019-05-09 21:47   ` Jeffrey Vander Stoep
  0 siblings, 1 reply; 9+ messages in thread
From: Stephen Smalley @ 2019-05-09 21:11 UTC (permalink / raw)
  To: Jeffrey Vander Stoep, selinux, 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.

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Mislabeled /proc/<pid>/ns/mnt files?
  2019-05-09 21:11 ` Stephen Smalley
@ 2019-05-09 21:47   ` Jeffrey Vander Stoep
  2019-05-10  7:12     ` Dominick Grift
       [not found]     ` <CAB9W1A2LPEk_XixkFU5mVgr9c2yNoiGzBjXYjpc3vDM1b2VpyA@mail.gmail.com>
  0 siblings, 2 replies; 9+ messages in thread
From: Jeffrey Vander Stoep @ 2019-05-09 21:47 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: selinux, Joel Galenson, Petr Lautrbach

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Mislabeled /proc/<pid>/ns/mnt files?
  2019-05-09 21:47   ` Jeffrey Vander Stoep
@ 2019-05-10  7:12     ` Dominick Grift
  2019-05-10 14:28       ` Stephen Smalley
       [not found]     ` <CAB9W1A2LPEk_XixkFU5mVgr9c2yNoiGzBjXYjpc3vDM1b2VpyA@mail.gmail.com>
  1 sibling, 1 reply; 9+ messages in thread
From: Dominick Grift @ 2019-05-10  7:12 UTC (permalink / raw)
  To: Jeffrey Vander Stoep
  Cc: Stephen Smalley, selinux, Joel Galenson, Petr Lautrbach

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Mislabeled /proc/<pid>/ns/mnt files?
       [not found]     ` <CAB9W1A2LPEk_XixkFU5mVgr9c2yNoiGzBjXYjpc3vDM1b2VpyA@mail.gmail.com>
@ 2019-05-10 12:38       ` Stephen Smalley
  2019-05-10 14:55         ` Stephen Smalley
  0 siblings, 1 reply; 9+ messages in thread
From: Stephen Smalley @ 2019-05-10 12:38 UTC (permalink / raw)
  To: Jeffrey Vander Stoep
  Cc: selinux, Joel Galenson, Petr Lautrbach, Lukas Vrabec, Paul Moore,
	Ondrej Mosnacek

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Mislabeled /proc/<pid>/ns/mnt files?
  2019-05-10  7:12     ` Dominick Grift
@ 2019-05-10 14:28       ` Stephen Smalley
  2019-05-10 14:40         ` Dominick Grift
  0 siblings, 1 reply; 9+ messages in thread
From: Stephen Smalley @ 2019-05-10 14:28 UTC (permalink / raw)
  To: Jeffrey Vander Stoep, selinux, Joel Galenson, Petr Lautrbach,
	Paul Moore, Ondrej Mosnacek

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Mislabeled /proc/<pid>/ns/mnt files?
  2019-05-10 14:28       ` Stephen Smalley
@ 2019-05-10 14:40         ` Dominick Grift
  0 siblings, 0 replies; 9+ messages in thread
From: Dominick Grift @ 2019-05-10 14:40 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Jeffrey Vander Stoep, selinux, Joel Galenson, Petr Lautrbach,
	Paul Moore, Ondrej Mosnacek

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Mislabeled /proc/<pid>/ns/mnt files?
  2019-05-10 12:38       ` Stephen Smalley
@ 2019-05-10 14:55         ` Stephen Smalley
  2019-05-14 20:13           ` Stephen Smalley
  0 siblings, 1 reply; 9+ messages in thread
From: Stephen Smalley @ 2019-05-10 14:55 UTC (permalink / raw)
  To: Jeffrey Vander Stoep
  Cc: selinux, Joel Galenson, Petr Lautrbach, Lukas Vrabec, Paul Moore,
	Ondrej Mosnacek

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.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Mislabeled /proc/<pid>/ns/mnt files?
  2019-05-10 14:55         ` Stephen Smalley
@ 2019-05-14 20:13           ` Stephen Smalley
  0 siblings, 0 replies; 9+ messages in thread
From: Stephen Smalley @ 2019-05-14 20:13 UTC (permalink / raw)
  To: Jeffrey Vander Stoep
  Cc: selinux, Joel Galenson, Petr Lautrbach, Lukas Vrabec, Paul Moore,
	Ondrej Mosnacek

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-09 19:56 Mislabeled /proc/<pid>/ns/mnt files? Jeffrey Vander Stoep
2019-05-09 21:11 ` Stephen Smalley
2019-05-09 21:47   ` Jeffrey Vander Stoep
2019-05-10  7:12     ` Dominick Grift
2019-05-10 14:28       ` Stephen Smalley
2019-05-10 14:40         ` Dominick Grift
     [not found]     ` <CAB9W1A2LPEk_XixkFU5mVgr9c2yNoiGzBjXYjpc3vDM1b2VpyA@mail.gmail.com>
2019-05-10 12:38       ` Stephen Smalley
2019-05-10 14:55         ` Stephen Smalley
2019-05-14 20:13           ` Stephen Smalley

SELinux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \
		selinux@vger.kernel.org selinux@archiver.kernel.org
	public-inbox-index selinux


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux


AGPL code for this site: git clone https://public-inbox.org/ public-inbox