From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 0A9A62C49 for ; Thu, 9 Mar 2017 16:48:43 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6373772984; Thu, 9 Mar 2017 15:48:43 +0000 (UTC) Received: from dhcp-25-97.bos.redhat.com ([10.18.25.172]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v29Fmfxl012766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 10:48:42 -0500 From: Aaron Conole To: Daniele Di Proietto Cc: Ansis Atteka , "\" , dev@dpdk.org References: <20170125022225.28883-1-diproiettod@vmware.com> <1F6C7DEC-0479-4A3F-B7BE-82BAB21D6537@vmware.com> <0CBAA34C-3F71-4C70-8B9E-59BD00E7FF68@vmware.com> Date: Thu, 09 Mar 2017 10:48:41 -0500 In-Reply-To: (Aaron Conole's message of "Tue, 28 Feb 2017 17:21:17 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 09 Mar 2017 15:48:43 +0000 (UTC) Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [ovs-dev] [PATCH] selinux: Allow creating tap devices. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:48:43 -0000 Aaron Conole writes: > Daniele Di Proietto writes: > >> On 26/01/2017 12:35, "Ansis Atteka" wrote: >>> >>> >>>On 26 January 2017 at 21:24, Aaron Conole >>> wrote: >>> >>>Daniele Di Proietto writes: >>> >>>> On 25/01/2017 00:01, "Ansis Atteka" wrote: >>>> >>>>>On Jan 25, 2017 4:22 AM, "Daniele Di Proietto" 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 >>> >>>I just noticed this, sorry for jumping in late. >>> >>>>>Acked-by: Ansis Atteka >>>>> >>>>> >>>>>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. >> +1, thanks a lot >>> >>> >>> >>>-------------------- 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. >> Ok, so perhaps we should require tun_tap_device_t permissions only if >> we enable userspace support with a boolean. >> I just posted this piece because the corresponding code is in >> openvswitch source tree. >> The rest of the permissions (hugepages, vfio) are required because of >> code that's in the dpdk library. Is there a way to put these in DPDK >> and then just call a macro here, like >> dpdk_perms(openvswitch_t) > > Below is an example of the macro: > > -------------------- 8< -------------------- > > define(`dpdk_perms', ` > gen_require(` > type vfio_device_t; > type kernel_t; > type hugetlbfs_t; > 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 }; > ') > > allow $1_t vfio_device_t:chr_file { read write open ioctl getattr }; > allow $1_t hugetlbfs_t:dir { write remove_name add_name lock read }; > allow $1_t hugetlbfs_t:file { create unlink }; > allow $1_t kernel_t:unix_stream_socket { write getattr read connectto > connect setopt getopt sendto accept bind recvfrom acceptfrom }; > ') > > -------------------- >8 -------------------- > > And then it can be called at the end of the .te file as: > > dpdk_perms(openvswitch) > > I am not sure how best to install this in the end system to make sure > that it gets included properly - I'll ask around here and maybe get an > answer (or even post a patch to the dpdk mailing list). I did try > making a .te file with this macro and a policy definition, but I wasn't > able to reference it from within openvswitch-custom.te; most likely I > will need to figure out where my configuration is wrong. So, here's what I've done so far with the above; I'm running with the attached patch - admittedly, it needs to be integrated so that it can be disabled/enabled based on --with-dpdk flag. I have tested it out, and it seems to work - I've passed some traffic, and am able to run (as non-root user, even! :) through some basic traffic scenarios. Do you think it's the right thing now to integrate this into the configure/make system so that openvswitch-custom.te can use the macro when dpdk is enabled? -Aaron