From: Stephen Smalley <sds@xxxxxxxxxxxxx> Date: Thu, May 9, 2019 at 2:17 PM To: Jeffrey Vander Stoep, <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.
