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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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.





[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux