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

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

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.