Put in libx32 subs entries that refer to directories with fc entries.
Allow dpkg_t to transition to dpkg_script_t when it executes bin_t for
dpkg-reconfigure.
Some dontaudit rules for mta processes spawned by mon for notification.
Lots of tiny changes that are obvious.
Define new netlink socket security classes introduced by kernel commit
223ae516404a7a65f09e79a1c0291521c233336e.
Note that this does not remove the long-since obsolete
netlink_firewall_socket and netlink_ip6_fw_socket classes
from refpolicy in case they are still needed for legacy
distribution policies.
Add the new socket classes to socket_class_set.
Update ubac and mls constraints for the new socket classes.
Add allow rules for a few specific known cases (netutils, iptables,
netlabel, ifconfig, udev) in core policy that require access.
Further refinement for the contrib tree will be needed. Any allow
rule previously written on :netlink_socket may need to be rewritten or
duplicated for one of the more specific classes. For now, we retain the
existing :netlink_socket rules for compatibility on older kernels.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
If the (sadly nearly undocumented) Linux kernel feature which allows
specific user groups to send ICMP echos without CAP_NET_RAW
(configurable with the sysctl net.ipv4.ping_group_range, available since
3.0) is used, ping needs the getattr permission of the rawip_socket
class in order to work.
When ping is installed with capabilities instead of being marked setuid,
then the ping_t domain needs to be allowed to getcap/setcap.
Reported-by: Luis Ressel <aranea@aixah.de>
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
When invoking tcpdump, the application creates a netlink_socket and then chroots
into /var/lib/tcpdump.
Without the right to create a netlink_socket:
tcpdump: Can't open netlink socket 13:Permission denied
Without the right on dac_read_search and sys_chroot:
tcpdump: Couldn't chroot/chdir to '/var/lib/tcpdump': Permission denied
See also https://bugs.gentoo.org/show_bug.cgi?id=443624
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
