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
