On Wed, Jan 29, 2020 at 11:45 AM Christian Göttsche <cgzones@xxxxxxxxxxxxxx> wrote: > Am Mi., 29. Jan. 2020 um 14:34 Uhr schrieb Stephen Smalley <sds@xxxxxxxxxxxxx>: > > This looks fine to me code-wise. Have you tried enabling this new > > policy capability in policy and seeing the effects of it? I remember a > > problem in the way-back time that motivated adding the S_ISLNK() > > exception for proc. IIRC, the issue was that policies specified > > "genfscon proc /net system_u:object_r:proc_net_t:s0" to label everything > > under /proc/net with proc_net_t by default, and when /proc/net was > > changed to be a symlink to /proc/self/net as part of the network > > namespaces work, this caused the symlink to be labeled proc_net_t, but > > since previously there were no symlinks labeled proc_net_t, no processes > > were allowed to read/follow the symlink and existing systems broke. > > Exempting symlinks caused the /proc/net symlink to be labeled proc_t > > instead, which was already widely allowed. To avoid this problem when > > enabling this capability, you will either need to allow > > proc_net_t:lnk_file read widely or you will need to change the genfscon > > statement to avoid labeling the symlink (there is an optional file mode > > field in genfscon statements similar to that of file_contexts, e.g. > > genfscon proc /net -d system_u:object_r:proc_net_t:s0 > > genfscon proc /net -- system_u:object_r:proc_net_t:s0 > > would only label directories and regular files with proc_net_t. > > I tested it with a refpolicy alike policy, where > kernel_read_network_state() allows access to symlinks [1]. > Just systemd pid 1 wants to read the symlink only without reading any > files, so I added kernel_search_network_state(systemd_t). > > [1]: https://github.com/SELinuxProject/refpolicy/blob/7e191b008e70ca535ceca2405967ddddd2ed975d/policy/modules/kernel/kernel.if#L1437 Thanks. FWIW, I think the netns procfs case is a little different simply because it was a change in the core kernel behavior and not a change in the access controls. While we have tricks, e.g. policy capabilities, to help with migrating users/admins to new access control changes, we don't always have the same abilities when the core kernel changes. One could make the argument that the netns procfs change was a "break userspace" type of change, but I doubt you would have gotten far with that because well ... containers. Anyway, I've gone ahead and queued the patch up in selinux/next, you should see it in the tree once the merge window closes. -- paul moore www.paul-moore.com
