On 5/9/19 8:32 PM, Stephen Smalley wrote:
On Thu, May 9, 2019, 5:49 PM Jeffrey Vander Stoep <jeffv@xxxxxxxxxx
<mailto:jeffv@xxxxxxxxxx>> wrote:
From: Stephen Smalley <sds@xxxxxxxxxxxxx <mailto:sds@xxxxxxxxxxxxx>>
Date: Thu, May 9, 2019 at 2:17 PM
To: Jeffrey Vander Stoep, <selinux@xxxxxxxxxxxxxxx
<mailto: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.
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.
