From: pebenito@ieee.org (Chris PeBenito) Date: Thu, 15 Feb 2018 17:03:06 -0500 Subject: [refpolicy] rawip_socket permissions In-Reply-To: <3088676.kIsrdd9GrL@xev> References: <3088676.kIsrdd9GrL@xev> Message-ID: <1fe28c0b-7dd2-fc61-85e3-df8b8cc27742@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 02/13/2018 08:17 AM, Russell Coker via refpolicy wrote: > I was working on NetworkManager policy and needed to write policy for > rawip_socket access. As there wasn't a macro specifying the permissions > needed I decided to grep the existing policy to see what others have done, > this shows the need for such a macro: > > admin/netutils.te:allow traceroute_t self:rawip_socket create_socket_perms; > admin/netutils.te:allow ping_t self:rawip_socket { create ioctl read write > bind getopt setopt getattr }; > > Two different uses in the one file. I hope I didn't write that. > > contrib/automount.te:allow automount_t self:rawip_socket create_socket_perms; > contrib/collectd.te:allow collectd_t self:rawip_socket create_socket_perms; > contrib/cups.te:allow hplip_t self:rawip_socket create_socket_perms; > contrib/iodine.te:allow iodined_t self:rawip_socket create_socket_perms; > contrib/l2tp.te:allow l2tpd_t self:rawip_socket create_socket_perms; > contrib/nessus.te:allow nessusd_t self:rawip_socket create_socket_perms; > contrib/openvswitch.te:allow openvswitch_t self:rawip_socket > create_socket_perms; > contrib/ppp.te:allow pptp_t self:rawip_socket create_socket_perms; > contrib/psad.te:allow psad_t self:rawip_socket create_socket_perms; > contrib/radvd.te:allow radvd_t self:rawip_socket create_socket_perms; > contrib/rdisc.te:allow rdisc_t self:rawip_socket create_socket_perms; > contrib/vmware.te:allow vmware_host_t self:rawip_socket create_socket_perms; > contrib/vpn.te:allow vpnc_t self:rawip_socket create_socket_perms; > contrib/watchdog.te:allow watchdog_t self:rawip_socket create_socket_perms; > contrib/zebra.te:allow zebra_t self:rawip_socket create_socket_perms; > contrib/pingd.te:allow pingd_t self:rawip_socket create_socket_perms; > contrib/dhcp.te:allow dhcpd_t self:rawip_socket create_socket_perms; > contrib/dnsmasq.te:allow dnsmasq_t self:rawip_socket create_socket_perms; > contrib/virt.te:allow virtd_t self:rawip_socket create_socket_perms; > contrib/virt.te:allow svirt_lxc_net_t self:rawip_socket create_socket_perms; > system/udev.te:allow udev_t self:rawip_socket create_socket_perms; > system/modutils.te:allow kmod_t self:rawip_socket create_socket_perms; > system/systemd.te:allow systemd_networkd_t self:rawip_socket > create_socket_perms; > system/iptables.te:allow iptables_t self:rawip_socket create_socket_perms; > system/sysnetwork.te:allow dhcpc_t self:rawip_socket create_socket_perms; > > create_socket_perms is the obvious favourite, while the rawip_socket class > inherits everything from socket, is there anything that actually does a bind > or connect operation on rawip? I guess there's no harm having an allow rule > for something that can't happen, but it's confusing if nothing else. > > contrib/monit.te:allow monit_t self:rawip_socket connected_socket_perms; > contrib/squid.te: allow squid_t self:rawip_socket > connected_socket_perms; > > The same for connected_socket_perms, it allows bind but not connect. > > contrib/telepathy.te:allow telepathy_sofiasip_t self:rawip_socket > create_stream_socket_perms; > > create_stream_socket_perms has the obvious issue that rawip is not a stream, > but also listen and accept aren't operations that are going to happen on > rawip. > > contrib/portage.if: allow $1 self:rawip_socket { create ioctl }; > > I wonder what this is about. I guess it's possible that some code in portage > creates a rawip socket but does nothing with it, but if so that would be a bug > in the code. It could be that the code creates a rawip socket and then gets > an error when it can't use it. Since it is for a domain that does the package compiling, it could easily be some random package that triggered that. > define(`rawip_socket_perms', `{ create getopt setopt getattr read write }') > > Maybe we need something like the above in the policy. In a quick test I > couldn't get any other access to be used. I've hoped for better socket permission sets, but the verbs for the permission set names elude me. I'm open to suggestions, though I'd prefer the permission sets include verbs (or their abbreviations, such as "rw") to help convey meaning. > Why does hplip need rawip access? Is it for mDNS? I think we need a boolean > for that, I don't want my print server reading all network traffic. > > Why does collectd need rawip access? Is it for multicast? > > This is a first analysis of the issue. After getting suggestions I'll write a > patch, test it on a few different systems, and send it for discussion. > -- Chris PeBenito