The implementation for NETLINK_FIREWALL and NETLINK_IP6_FW protocols
was removed from the kernel in commit
d16cf20e2f2f13411eece7f7fb72c17d141c4a84 ("netfilter: remove ip_queue
support") circa Linux 3.5. Consequently, kernels >= 3.5 should never
perform permission checks on these classes although they remained
defined in the SELinux kernel classmap until the netlink classes
were updated by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6c6d2e9bde1c1c87a7ead806f8f5e2181d41a652
circa Linux v4.2.
Removing these class definitions would break legacy userspace that relies
upon stable values for the userspace security class definitions since it
will perturb those values by removing classes that preceded them. dbus-daemon
in particular is known to break if its dbus class changes at runtime,
which could occur upon a policy reload that removes these classes.
Fixing this requires ensuring that dbus-daemon looks up the appropriate
class value on each use or upon policy reload, via userspace interfaces
such as selinux_check_access(), string_to_security_class(), and/or
selinux_set_callback(SELINUX_CB_POLICYLOAD, ...) with a callback function
that remaps the class value if needed. Other userspace policy enforcers
are believed to have been updated in recent versions but older versions
may break upon such a change.
Hence, this change renames these classes with obsolete_ prefixes and
removes all rules referencing them from refpolicy, thereby preserving
the class numbering for subsequent classes while making it clear that
these classses are no longer meaningful for modern kernels.
This change does however create a potential compatibility break for
kernels < 3.5, since the policy will cease to define the kernel class
names and therefore the kernel will handle permission checks on the
class based on the handle_unknown setting in policy. For most
Linux distributions, this will default to allow and therefore avoid
breaking userspace but will fail open. For kernels < 2.6.33 (i.e.
the dynamic class/perm discovery support), the presence of a class
in policy with the same number but a different name than the kernel
class will cause the policy load to fail entirely.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
5fd175fa45