All of lore.kernel.org
 help / color / mirror / Atom feed
From: russell@coker.com.au (Russell Coker)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] rawip_socket permissions
Date: Wed, 14 Feb 2018 00:17:04 +1100	[thread overview]
Message-ID: <3088676.kIsrdd9GrL@xev> (raw)

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/

             reply	other threads:[~2018-02-13 13:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-13 13:17 Russell Coker [this message]
2018-02-15 22:03 ` [refpolicy] rawip_socket permissions Chris PeBenito
2018-02-16  6:02   ` Russell Coker
2018-02-18 16:13     ` Chris PeBenito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3088676.kIsrdd9GrL@xev \
    --to=russell@coker.com.au \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.