[refpolicy] rawip_socket permissions

[refpolicy] rawip_socket permissions

[Russell Coker]

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.

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.

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.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] rawip_socket permissions

[Chris PeBenito]

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

[refpolicy] rawip_socket permissions

[Russell Coker]

On Friday, 16 February 2018 9:03:06 AM AEDT Chris PeBenito wrote:
> 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.

Is there a point in having a specific "rw" on rawip?  Having "rw" implies that 
something other than "rw" would be used, and does that make sense?  Do we have 
network sniffers having just read access?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] rawip_socket permissions

[Chris PeBenito]

On 02/16/2018 01:02 AM, Russell Coker wrote:
> On Friday, 16 February 2018 9:03:06 AM AEDT Chris PeBenito wrote:
>> 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.
> 
> Is there a point in having a specific "rw" on rawip?  Having "rw" implies that
> something other than "rw" would be used, and does that make sense?  Do we have
> network sniffers having just read access?

I wasn't saying that there had to be a rw set, just providing an example.

-- 
Chris PeBenito