* Mislabeled /proc/<pid>/ns/mnt files? @ 2019-05-09 19:56 Jeffrey Vander Stoep 2019-05-09 21:11 ` Stephen Smalley 0 siblings, 1 reply; 9+ messages in thread From: Jeffrey Vander Stoep @ 2019-05-09 19:56 UTC (permalink / raw) To: selinux, Joel Galenson 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mislabeled /proc/<pid>/ns/mnt files? 2019-05-09 19:56 Mislabeled /proc/<pid>/ns/mnt files? Jeffrey Vander Stoep @ 2019-05-09 21:11 ` Stephen Smalley 2019-05-09 21:47 ` Jeffrey Vander Stoep 0 siblings, 1 reply; 9+ messages in thread From: Stephen Smalley @ 2019-05-09 21:11 UTC (permalink / raw) To: Jeffrey Vander Stoep, selinux, 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. 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mislabeled /proc/<pid>/ns/mnt files? 2019-05-09 21:11 ` Stephen Smalley @ 2019-05-09 21:47 ` Jeffrey Vander Stoep 2019-05-10 7:12 ` Dominick Grift [not found] ` <CAB9W1A2LPEk_XixkFU5mVgr9c2yNoiGzBjXYjpc3vDM1b2VpyA@mail.gmail.com> 0 siblings, 2 replies; 9+ messages in thread From: Jeffrey Vander Stoep @ 2019-05-09 21:47 UTC (permalink / raw) To: Stephen Smalley; +Cc: selinux, Joel Galenson, Petr Lautrbach From: Stephen Smalley <sds@tycho.nsa.gov> Date: Thu, May 9, 2019 at 2:17 PM To: Jeffrey Vander Stoep, <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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mislabeled /proc/<pid>/ns/mnt files? 2019-05-09 21:47 ` Jeffrey Vander Stoep @ 2019-05-10 7:12 ` Dominick Grift 2019-05-10 14:28 ` Stephen Smalley [not found] ` <CAB9W1A2LPEk_XixkFU5mVgr9c2yNoiGzBjXYjpc3vDM1b2VpyA@mail.gmail.com> 1 sibling, 1 reply; 9+ messages in thread From: Dominick Grift @ 2019-05-10 7:12 UTC (permalink / raw) To: Jeffrey Vander Stoep Cc: Stephen Smalley, selinux, Joel Galenson, Petr Lautrbach [-- Attachment #1: Type: text/plain, Size: 2712 bytes --] On Thu, May 09, 2019 at 02:47:30PM -0700, Jeffrey Vander Stoep wrote: > From: Stephen Smalley <sds@tycho.nsa.gov> > Date: Thu, May 9, 2019 at 2:17 PM > To: Jeffrey Vander Stoep, <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. # 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. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mislabeled /proc/<pid>/ns/mnt files? 2019-05-10 7:12 ` Dominick Grift @ 2019-05-10 14:28 ` Stephen Smalley 2019-05-10 14:40 ` Dominick Grift 0 siblings, 1 reply; 9+ messages in thread From: Stephen Smalley @ 2019-05-10 14:28 UTC (permalink / raw) To: Jeffrey Vander Stoep, selinux, Joel Galenson, Petr Lautrbach, Paul Moore, Ondrej Mosnacek 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@tycho.nsa.gov> >> Date: Thu, May 9, 2019 at 2:17 PM >> To: Jeffrey Vander Stoep, <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. > > # 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mislabeled /proc/<pid>/ns/mnt files? 2019-05-10 14:28 ` Stephen Smalley @ 2019-05-10 14:40 ` Dominick Grift 0 siblings, 0 replies; 9+ messages in thread From: Dominick Grift @ 2019-05-10 14:40 UTC (permalink / raw) To: Stephen Smalley Cc: Jeffrey Vander Stoep, selinux, Joel Galenson, Petr Lautrbach, Paul Moore, Ondrej Mosnacek [-- Attachment #1: Type: text/plain, Size: 3785 bytes --] On Fri, May 10, 2019 at 10:28:50AM -0400, Stephen Smalley wrote: > 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@tycho.nsa.gov> > > > Date: Thu, May 9, 2019 at 2:17 PM > > > To: Jeffrey Vander Stoep, <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. > > > > # 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. I would appreciate that, yes. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <CAB9W1A2LPEk_XixkFU5mVgr9c2yNoiGzBjXYjpc3vDM1b2VpyA@mail.gmail.com>]
* Re: Mislabeled /proc/<pid>/ns/mnt files? [not found] ` <CAB9W1A2LPEk_XixkFU5mVgr9c2yNoiGzBjXYjpc3vDM1b2VpyA@mail.gmail.com> @ 2019-05-10 12:38 ` Stephen Smalley 2019-05-10 14:55 ` Stephen Smalley 0 siblings, 1 reply; 9+ messages in thread From: Stephen Smalley @ 2019-05-10 12:38 UTC (permalink / raw) To: Jeffrey Vander Stoep Cc: selinux, Joel Galenson, Petr Lautrbach, Lukas Vrabec, Paul Moore, Ondrej Mosnacek 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mislabeled /proc/<pid>/ns/mnt files? 2019-05-10 12:38 ` Stephen Smalley @ 2019-05-10 14:55 ` Stephen Smalley 2019-05-14 20:13 ` Stephen Smalley 0 siblings, 1 reply; 9+ messages in thread From: Stephen Smalley @ 2019-05-10 14:55 UTC (permalink / raw) To: Jeffrey Vander Stoep Cc: selinux, Joel Galenson, Petr Lautrbach, Lukas Vrabec, Paul Moore, Ondrej Mosnacek 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mislabeled /proc/<pid>/ns/mnt files? 2019-05-10 14:55 ` Stephen Smalley @ 2019-05-14 20:13 ` Stephen Smalley 0 siblings, 0 replies; 9+ messages in thread From: Stephen Smalley @ 2019-05-14 20:13 UTC (permalink / raw) To: Jeffrey Vander Stoep Cc: selinux, Joel Galenson, Petr Lautrbach, Lukas Vrabec, Paul Moore, Ondrej Mosnacek 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-05-14 20:22 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-09 19:56 Mislabeled /proc/<pid>/ns/mnt files? Jeffrey Vander Stoep
2019-05-09 21:11 ` Stephen Smalley
2019-05-09 21:47 ` Jeffrey Vander Stoep
2019-05-10 7:12 ` Dominick Grift
2019-05-10 14:28 ` Stephen Smalley
2019-05-10 14:40 ` Dominick Grift
[not found] ` <CAB9W1A2LPEk_XixkFU5mVgr9c2yNoiGzBjXYjpc3vDM1b2VpyA@mail.gmail.com>
2019-05-10 12:38 ` Stephen Smalley
2019-05-10 14:55 ` Stephen Smalley
2019-05-14 20:13 ` Stephen Smalley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).