[ovs-dev] [PATCH] selinux: Allow creating tap devices.

[Ansis Atteka]

On 26 January 2017 at 21:24, Aaron Conole <aconole at redhat.com> wrote:

> Daniele Di Proietto <diproiettod at vmware.com> writes:
>
> > On 25/01/2017 00:01, "Ansis Atteka" <ansisatteka at gmail.com> wrote:
> >
> >>On Jan 25, 2017 4:22 AM, "Daniele Di Proietto" <diproiettod at vmware.com>
> wrote:
> >>
> >>Current SELinux policy in RHEL and Fedora doesn't allow the creation of
> >>TAP devices.
> >>
> >>A tap device is used by dpif-netdev to create internal devices.
> >>
> >>Without this patch, adding any bridge backed by the userspace datapath
> >>would fail.
> >>
> >>This doesn't mean that we can run Open vSwitch with DPDK under SELinux
> >>yet, but at least we can use the userspace datapath.
> >>
> >>Signed-off-by: Daniele Di Proietto <diproiettod at vmware.com>
>
> I just noticed this, sorry for jumping in late.
>
> >>Acked-by: Ansis Atteka <aatteka at ovn.org>
> >>
> >>
> >>I saw that other open source projects like OpenVPN use rw_file_perms
> >> shortcut macro. Not sure how relevant that is for OVS but that macro
> >> expands to a little more function calls than what you have
> >> below. Maybe we don't need it, if what you have
> >> just worked.
> >
> > Thanks a lot for the review.
> >
> > I cooked this up using audit2allow and I tested it on fedora 25.  I'm
> > now able to create and delete userspace bridges, without any further
> > complaints from selinux
>
> I have the following openvswitch-custom.te that did work to run
> ovs+dpdk under selinux and pass traffic:
>
Thanks for posting this. I think that this is really helpful to gather all
necessary OVS+DPDK rules from different sources to make sure that nothing
is missed.

>
> -------------------- 8< --------------------
>
> require {
>         type openvswitch_t;
>         type openvswitch_tmp_t;
>         type openvswitch_var_run_t;
>         type ifconfig_exec_t;
>         type hostname_exec_t;
>         type vfio_device_t;
>         type kernel_t;
>         type tun_tap_device_t;
>         type hugetlbfs_t;
>         type init_t;
>         class netlink_socket { setopt getopt create connect getattr write
> read };
>         class file { write getattr read open execute execute_no_trans
> create unlink };
>         class chr_file { write getattr read open ioctl };
>         class unix_stream_socket { write getattr read connectto connect
> setopt getopt sendto accept bind recvfrom acceptfrom };
>         class dir { write remove_name add_name lock read };
> }
>
> #============= openvswitch_t ==============
> allow openvswitch_t self:netlink_socket { setopt getopt create connect
> getattr write read };
> allow openvswitch_t hostname_exec_t:file { read getattr open execute
> execute_no_trans };
> allow openvswitch_t ifconfig_exec_t:file { read getattr open execute
> execute_no_trans };
> allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };
> allow openvswitch_t openvswitch_tmp_t:unix_stream_socket { write getattr
> read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom
> };
> allow openvswitch_t vfio_device_t:chr_file { read write open ioctl getattr
> };
> allow openvswitch_t tun_tap_device_t:chr_file { read write getattr open
> ioctl };
> allow openvswitch_t hugetlbfs_t:dir { write remove_name add_name lock read
> };
> allow openvswitch_t hugetlbfs_t:file { create unlink };
> allow openvswitch_t kernel_t:unix_stream_socket { write getattr read
> connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };
> allow openvswitch_t init_t:file { read open };
>
> -------------------- >8 --------------------
>
> You'll note that this change gives the openvswitch complete access to
> hugetlbfs label, which might be the biggest scary part.
>
There is also option to use SELinux switches that allow to activate only
subset of SElinux rules on a "per OVS feature basis" if there is risk that
because of DPDK whitelise we could be unconditionally loosening up SElinux
policy too much for non-DPDK cases. See [
https://wiki.centos.org/TipsAndTricks/SelinuxBooleans] for more details.


>
> > I'm definitely not an expert in SELinux, so I'm not sure if it's
> > better to use the macro and ask for extra permission, or to hardcode
> > the list.
> >
> > What do you think?
>

> For macro usage?  I haven't messed with them at all.  I'll note that

I guess I don't have a strong opinion about macros. I think that as long as
nothing is missed and given OVS features works as expected we are good.
Anyway, probably Linux distribution maintainers should have final say about
this if this gets up-streamed to the main SELinux policy repository at
https://github.com/TresysTechnology/refpolicy/wiki


>
> https://github.com/redhat-openstack/openstack-selinux/pull/5/commits/
> 67606ffa6ea85db73e1955868f53848e05096bf0
>
> has what appear to be these macros in a .te file, but I'm going to echo
> what is previously written: I'm not an selinux expert.


> -Aaron
>