On 1/28/20 2:16 PM, Christian Göttsche wrote:
Currently symlinks on kernel filesystems, like sysfs, are labeled on creation with the parent filesystem root sid. Allow symlinks to inherit the parent directory context, so fine-grained kernfs labeling can be applied to symlinks too and checking contexts doesn't complain about them. For backward-compatibility this behavior is contained in a new policy capability: genfs_seclabel_symlinks Signed-off-by: Christian Göttsche <cgzones@xxxxxxxxxxxxxx>
(pruned cc list to omit non-selinux kernel maintainers since this change is entirely self-contained to selinux; I'm guessing you blindly took the results of scripts/get_maintainer.pl which tends to over-approximate - I only use it as a guide/hint and rarely use the full list it provides.)
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. Acked-by: Stephen Smalley <sds@xxxxxxxxxxxxx> [...]
