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@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.
# 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.
