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/
next 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.