[{"id":1761227,"web_url":"http://patchwork.ozlabs.org/comment/1761227/","msgid":"","list_archive_url":null,"date":"2017-08-31T17:52:34","subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","submitter":{"id":17389,"url":"http://patchwork.ozlabs.org/api/people/17389/","name":"Ansis","email":"ansisatteka@gmail.com"},"content":"On 30 August 2017 at 07:00, Aaron Conole wrote:\n> The selinux policy that exists in the repository did not specify access to\n> all of the resources needed for Open vSwitch to properly function with\n> an enforcing selinux policy. This update allows Open vSwitch to operate\n> with selinux set to Enforcing mode, even while running as a non-root user.\n>\n> Acked-by: Flavio Leitner \n> Signed-off-by: Aaron Conole \n> Tested-by: Jean Hsiao \n> ---\n> selinux/openvswitch-custom.te.in | 40 +++++++++++++++++++++++++++++++++++++++-\n> 1 file changed, 39 insertions(+), 1 deletion(-)\n>\n> diff --git a/selinux/openvswitch-custom.te.in b/selinux/openvswitch-custom.te.in\n> index 47ddb56..66cb678 100644\n> --- a/selinux/openvswitch-custom.te.in\n> +++ b/selinux/openvswitch-custom.te.in\n> @@ -2,15 +2,53 @@ module openvswitch-custom 1.0.1;\n>\n> require {\n> type openvswitch_t;\n> + type openvswitch_rw_t;\n> type openvswitch_tmp_t;\n> + type openvswitch_var_run_t;\n> +\n> type ifconfig_exec_t;\n> type hostname_exec_t;\n> + type tun_tap_device_t;\n> +\n> +@begin_dpdk@\n> + type hugetlbfs_t;\n> + type kernel_t;\n> + type svirt_image_t;\n> + type vfio_device_t;\n> +@end_dpdk@\n> +\n> + class capability { dac_override audit_write };\n> + class dir { write remove_name add_name lock read };\n> + class file { write getattr read open execute execute_no_trans create unlink };\n> + class netlink_audit_socket { create nlmsg_relay audit_write read write };\n> class netlink_socket { setopt getopt create connect getattr write read };\n> - class file { write getattr read open execute execute_no_trans };\n> + class unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n> +\n> +@begin_dpdk@\n> + class chr_file { write getattr read open ioctl };\n> + class tun_socket { relabelfrom relabelto create };\n> +@end_dpdk@\n> }\n>\n> #============= openvswitch_t ==============\n> +allow openvswitch_t self:capability { dac_override audit_write };\n> +allow openvswitch_t self:netlink_audit_socket { create nlmsg_relay audit_write read write };\n> allow openvswitch_t self:netlink_socket { setopt getopt create connect getattr write read };\n> +\n> allow openvswitch_t hostname_exec_t:file { read getattr open execute execute_no_trans };\n> allow openvswitch_t ifconfig_exec_t:file { read getattr open execute execute_no_trans };\n> +\n> +allow openvswitch_t openvswitch_rw_t:dir { write remove_name add_name lock read };\n> +allow openvswitch_t openvswitch_rw_t:file { write getattr read open execute execute_no_trans create unlink };\n> allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };\n> +allow openvswitch_t openvswitch_tmp_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n> +\n> +@begin_dpdk@\n> +allow openvswitch_t hugetlbfs_t:dir { write remove_name add_name lock read };\n> +allow openvswitch_t hugetlbfs_t:file { create unlink };\n> +allow openvswitch_t kernel_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n> +allow openvswitch_t self:tun_socket { relabelfrom relabelto create };\n\nCan you give an example why above rule is required? I believe it\nallows processes running under openvswitch_t type to change labels? I\nbelieve by having such rule the \"Mandatory\" access control becomes\nkinda like \"Discretionary\" in sense that process has now some\ndiscretion to alter SELinux policy.\n\n> +allow openvswitch_t svirt_image_t:file { getattr read write };\n> +allow openvswitch_t tun_tap_device_t:chr_file { read write getattr open ioctl };\n> +allow openvswitch_t vfio_device_t:chr_file { read write open ioctl getattr };\n> +@end_dpdk@\n\nIIRC some time ago I mentioned that DPDK policy MAY be extended for\nDPDK via SELinux booleans\n[https://wiki.centos.org/TipsAndTricks/SelinuxBooleans]. I guess there\nwas an issue why you did not want to pursue that path?\n\nOther than that this patch looks good to me. I hope you tested it on\nRHEL and Fedora?","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"TvQD1g3z\"; dkim-atps=neutral"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjqj14tWCz9s7c\n\tfor ;\n\tFri, 1 Sep 2017 03:52:53 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 53E179B9;\n\tThu, 31 Aug 2017 17:52:39 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 401DC9B9\n\tfor ; Thu, 31 Aug 2017 17:52:38 +0000 (UTC)","from mail-lf0-f68.google.com (mail-lf0-f68.google.com\n\t[209.85.215.68])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4AB5D1E5\n\tfor ; Thu, 31 Aug 2017 17:52:37 +0000 (UTC)","by mail-lf0-f68.google.com with SMTP id l140so190578lfg.3\n\tfor ; Thu, 31 Aug 2017 10:52:37 -0700 (PDT)","by 10.46.82.214 with HTTP; Thu, 31 Aug 2017 10:52:34 -0700 (PDT)"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=13Y6BrK3hZhZ+kQ9tnzXcaEN0WK9GVE5T3RpS6ke63U=;\n\tb=TvQD1g3zwYiSTOJpERGtCwZwjGCLhLUezmnFgupShA9LoUrh/WjMl5kurhzbIbNEsQ\n\t80Et+VFhL8tcdlQQyQuxAVhE2yqN5yFVVAAV+PQaeZhbfczjXOJmBimViXP1SDhLzLH5\n\tYQdUYBgeij27PQWAeEDltnPSGD7236Yf/r673op4nHdRwfCyR/EK+CIr9OVBozOM6T7n\n\tbswE/y2I4N6vK3U+XJK4aSzPTa+Ztahq6Udba8JztJ7c2h1MQYXlFIFDjCSTCM3L/0Ff\n\txTb517VnHOnqMRcCgzzw6KMxqCMFY/rm/Raji4kwE05MEI2/jIfUWMO/BOd0kY4jmViZ\n\tJLiA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=13Y6BrK3hZhZ+kQ9tnzXcaEN0WK9GVE5T3RpS6ke63U=;\n\tb=TNKdx9PJrpZseFCTsVi8A6Sby7PXlaikAaDTMDbLwW+K/swK6FomdFgwJ+0IDTnX1w\n\tM9RE4VmsAyG52msEcHDSe/ByNRhE7god7nY0OJKTnqTICed+ju9M38NO66rDwfcX1DlU\n\txj+1IRFEyV6E8uolUDHA++luKB9gs16pM3nzsSfH678nBS/sS73zjrXGYiVPzOLh8B3D\n\twoW/p2JE5jpYrrDW5yCBEcbYSD5EzHM3NU+crntQK3Z6A8wZ2O4rqMgwSi2V3Lf61di3\n\tNRDmLXz8Pn5vTOFY7GHS3gmlBy7JQ/cdSRpBPNayk4NSXQ2vwrmD9ATc6GxvhY9Xr7Ia\n\thGzg==","X-Gm-Message-State":"AHYfb5isIw0Yw2dFEX/28BuzytozZEDgVgL+yTek7/HZ09Xeyqke1UeW\n\tL7Rf3f5j5WT2es1qrjDR1ayP247gsA==","X-Google-Smtp-Source":"ADKCNb5vCJEzyoEaH4lTFDUEcDzSjwqj7DeqxCQhsCWQgUWEFBKMBYW7VhXzkcvNGtbvit9ZHxtZ/8fCizWKIAnFXgE=","X-Received":"by 10.46.19.9 with SMTP id 9mr1208461ljt.39.1504201955229;\n\tThu, 31 Aug 2017 10:52:35 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170830140035.22828-4-aconole@redhat.com>","References":"<20170830140035.22828-1-aconole@redhat.com>\n\t<20170830140035.22828-4-aconole@redhat.com>","From":"Ansis Atteka ","Date":"Thu, 31 Aug 2017 10:52:34 -0700","Message-ID":"","To":"Aaron Conole ","X-Spam-Status":"No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM\n\tautolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"\" ,\n\tFlavio Leitner , Ansis Atteka ","Subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1761268,"web_url":"http://patchwork.ozlabs.org/comment/1761268/","msgid":"","list_archive_url":null,"date":"2017-08-31T18:58:28","subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","submitter":{"id":67184,"url":"http://patchwork.ozlabs.org/api/people/67184/","name":"Aaron Conole","email":"aconole@redhat.com"},"content":"Hi Ansis,\n\nThanks for the review!\n\nAnsis Atteka writes:\n\n> On 30 August 2017 at 07:00, Aaron Conole wrote:\n>> The selinux policy that exists in the repository did not specify access to\n>> all of the resources needed for Open vSwitch to properly function with\n>> an enforcing selinux policy. This update allows Open vSwitch to operate\n>> with selinux set to Enforcing mode, even while running as a non-root user.\n>>\n>> Acked-by: Flavio Leitner \n>> Signed-off-by: Aaron Conole \n>> Tested-by: Jean Hsiao \n>> ---\n>> selinux/openvswitch-custom.te.in | 40 +++++++++++++++++++++++++++++++++++++++-\n>> 1 file changed, 39 insertions(+), 1 deletion(-)\n>>\n>> diff --git a/selinux/openvswitch-custom.te.in b/selinux/openvswitch-custom.te.in\n>> index 47ddb56..66cb678 100644\n>> --- a/selinux/openvswitch-custom.te.in\n>> +++ b/selinux/openvswitch-custom.te.in\n>> @@ -2,15 +2,53 @@ module openvswitch-custom 1.0.1;\n>>\n>> require {\n>> type openvswitch_t;\n>> + type openvswitch_rw_t;\n>> type openvswitch_tmp_t;\n>> + type openvswitch_var_run_t;\n>> +\n>> type ifconfig_exec_t;\n>> type hostname_exec_t;\n>> + type tun_tap_device_t;\n>> +\n>> +@begin_dpdk@\n>> + type hugetlbfs_t;\n>> + type kernel_t;\n>> + type svirt_image_t;\n>> + type vfio_device_t;\n>> +@end_dpdk@\n>> +\n>> + class capability { dac_override audit_write };\n>> + class dir { write remove_name add_name lock read };\n>> + class file { write getattr read open execute execute_no_trans create unlink };\n>> + class netlink_audit_socket { create nlmsg_relay audit_write read write };\n>> class netlink_socket { setopt getopt create connect getattr write read };\n>> - class file { write getattr read open execute execute_no_trans };\n>> + class unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>> +\n>> +@begin_dpdk@\n>> + class chr_file { write getattr read open ioctl };\n>> + class tun_socket { relabelfrom relabelto create };\n>> +@end_dpdk@\n>> }\n>>\n>> #============= openvswitch_t ==============\n>> +allow openvswitch_t self:capability { dac_override audit_write };\n>> +allow openvswitch_t self:netlink_audit_socket { create nlmsg_relay audit_write read write };\n>> allow openvswitch_t self:netlink_socket { setopt getopt create connect getattr write read };\n>> +\n>> allow openvswitch_t hostname_exec_t:file { read getattr open execute execute_no_trans };\n>> allow openvswitch_t ifconfig_exec_t:file { read getattr open execute execute_no_trans };\n>> +\n>> +allow openvswitch_t openvswitch_rw_t:dir { write remove_name add_name lock read };\n>> +allow openvswitch_t openvswitch_rw_t:file { write getattr read open execute execute_no_trans create unlink };\n>> allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };\n>> +allow openvswitch_t openvswitch_tmp_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>> +\n>> +@begin_dpdk@\n>> +allow openvswitch_t hugetlbfs_t:dir { write remove_name add_name lock read };\n>> +allow openvswitch_t hugetlbfs_t:file { create unlink };\n>> +allow openvswitch_t kernel_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>> +allow openvswitch_t self:tun_socket { relabelfrom relabelto create };\n>\n> Can you give an example why above rule is required? I believe it\n> allows processes running under openvswitch_t type to change labels? I\n> believe by having such rule the \"Mandatory\" access control becomes\n> kinda like \"Discretionary\" in sense that process has now some\n> discretion to alter SELinux policy.\n\nSo, as you point out it allows openvswitch_t to relabel from / to on\ntun_socket devices.\n\nInline are the related AVC message records I have.\n\n----------------------------- >8 --------------------------------\ntype=AVC msg=audit(1503426353.300:21402): avc: denied { relabelfrom } for pid=128134 comm=\"ovs-vswitchd\" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\ntype=AVC msg=audit(1503426353.300:21402): avc: denied { relabelto } for pid=128134 comm=\"ovs-vswitchd\" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\ntype=AVC msg=audit(1503426358.919:21406): avc: denied { create } for pid=128134 comm=\"ovs-vswitchd\" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n----------------------------- >8 --------------------------------\n\nI have to admit, I don't remember the exact details of what triggered\nthis particular AVC. When I get access to the testbed again, I can\nrecreate it and let you know (or post a follow up if required).\n\n>> +allow openvswitch_t svirt_image_t:file { getattr read write };\n>> +allow openvswitch_t tun_tap_device_t:chr_file { read write getattr open ioctl };\n>> +allow openvswitch_t vfio_device_t:chr_file { read write open ioctl getattr };\n>> +@end_dpdk@\n>\n> IIRC some time ago I mentioned that DPDK policy MAY be extended for\n> DPDK via SELinux booleans\n> [https://wiki.centos.org/TipsAndTricks/SelinuxBooleans]. I guess there\n> was an issue why you did not want to pursue that path?\n\nIt's one of administration. I've been trying to keep the overhead of\nenabling dpdk support very low. Using a boolean is an additional step\nout of the box. For most other projects (libvirt, etc.) it doesn't seem\nlike any additional out of the box configuration is needed to get a\nworking selinux configuration and have virtio (or other subsystems) work\nwith them, so I wanted to keep it that way.\n\nThere's basically no technical issue I see either way, it's one of\npreference. If you are really that concerned that you want a boolean, I\ncan do that, but it seemed inconvenient - and we can't accidentally open\nthe selinux policy too wide with non-dpdk enabled OvS since that is a\nbuild-time restriction.\n\n> Other than that this patch looks good to me. I hope you tested it on\n> RHEL and Fedora?\n\nYes, RHEL and Fedora (but I didn't test on CentOS). Also, usually I\ntest with dpdk-enabled. I did try to keep the rules correct for both\ncases, though.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=aconole@redhat.com"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjs8s37BSz9s7f\n\tfor ;\n\tFri, 1 Sep 2017 04:58:37 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 1ED73B0A;\n\tThu, 31 Aug 2017 18:58:33 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 3E15DA95\n\tfor ; Thu, 31 Aug 2017 18:58:31 +0000 (UTC)","from mx1.redhat.com (mx1.redhat.com [209.132.183.28])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id B78C8140\n\tfor ; Thu, 31 Aug 2017 18:58:30 +0000 (UTC)","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 3C60C4A6F1;\n\tThu, 31 Aug 2017 18:58:30 +0000 (UTC)","from dhcp-25-97.bos.redhat.com (unknown [10.18.25.172])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 8BF705F916;\n\tThu, 31 Aug 2017 18:58:29 +0000 (UTC)"],"X-Greylist":["domain auto-whitelisted by SQLgrey-1.7.6","Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.38]);\n\tThu, 31 Aug 2017 18:58:30 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 3C60C4A6F1","From":"Aaron Conole ","To":"Ansis Atteka ","References":"<20170830140035.22828-1-aconole@redhat.com>\n\t<20170830140035.22828-4-aconole@redhat.com>\n\t","Date":"Thu, 31 Aug 2017 14:58:28 -0400","In-Reply-To":"\n\t(Ansis Atteka's message of \"Thu, 31 Aug 2017 10:52:34 -0700\")","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.79 on 10.5.11.14","X-Spam-Status":"No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,\n\tRP_MATCHES_RCVD autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"\" ,\n\tFlavio Leitner , Ansis Atteka ","Subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1761303,"web_url":"http://patchwork.ozlabs.org/comment/1761303/","msgid":"","list_archive_url":null,"date":"2017-08-31T20:19:11","subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","submitter":{"id":17389,"url":"http://patchwork.ozlabs.org/api/people/17389/","name":"Ansis","email":"ansisatteka@gmail.com"},"content":"On 31 August 2017 at 11:58, Aaron Conole wrote:\n> Hi Ansis,\n>\n> Thanks for the review!\n>\n> Ansis Atteka writes:\n>\n>> On 30 August 2017 at 07:00, Aaron Conole wrote:\n>>> The selinux policy that exists in the repository did not specify access to\n>>> all of the resources needed for Open vSwitch to properly function with\n>>> an enforcing selinux policy. This update allows Open vSwitch to operate\n>>> with selinux set to Enforcing mode, even while running as a non-root user.\n>>>\n>>> Acked-by: Flavio Leitner \n>>> Signed-off-by: Aaron Conole \n>>> Tested-by: Jean Hsiao \n>>> ---\n>>> selinux/openvswitch-custom.te.in | 40 +++++++++++++++++++++++++++++++++++++++-\n>>> 1 file changed, 39 insertions(+), 1 deletion(-)\n>>>\n>>> diff --git a/selinux/openvswitch-custom.te.in b/selinux/openvswitch-custom.te.in\n>>> index 47ddb56..66cb678 100644\n>>> --- a/selinux/openvswitch-custom.te.in\n>>> +++ b/selinux/openvswitch-custom.te.in\n>>> @@ -2,15 +2,53 @@ module openvswitch-custom 1.0.1;\n>>>\n>>> require {\n>>> type openvswitch_t;\n>>> + type openvswitch_rw_t;\n>>> type openvswitch_tmp_t;\n>>> + type openvswitch_var_run_t;\n>>> +\n>>> type ifconfig_exec_t;\n>>> type hostname_exec_t;\n>>> + type tun_tap_device_t;\n>>> +\n>>> +@begin_dpdk@\n>>> + type hugetlbfs_t;\n>>> + type kernel_t;\n>>> + type svirt_image_t;\n>>> + type vfio_device_t;\n>>> +@end_dpdk@\n>>> +\n>>> + class capability { dac_override audit_write };\n>>> + class dir { write remove_name add_name lock read };\n>>> + class file { write getattr read open execute execute_no_trans create unlink };\n>>> + class netlink_audit_socket { create nlmsg_relay audit_write read write };\n>>> class netlink_socket { setopt getopt create connect getattr write read };\n>>> - class file { write getattr read open execute execute_no_trans };\n>>> + class unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>> +\n>>> +@begin_dpdk@\n>>> + class chr_file { write getattr read open ioctl };\n>>> + class tun_socket { relabelfrom relabelto create };\n>>> +@end_dpdk@\n>>> }\n>>>\n>>> #============= openvswitch_t ==============\n>>> +allow openvswitch_t self:capability { dac_override audit_write };\n>>> +allow openvswitch_t self:netlink_audit_socket { create nlmsg_relay audit_write read write };\n>>> allow openvswitch_t self:netlink_socket { setopt getopt create connect getattr write read };\n>>> +\n>>> allow openvswitch_t hostname_exec_t:file { read getattr open execute execute_no_trans };\n>>> allow openvswitch_t ifconfig_exec_t:file { read getattr open execute execute_no_trans };\n>>> +\n>>> +allow openvswitch_t openvswitch_rw_t:dir { write remove_name add_name lock read };\n>>> +allow openvswitch_t openvswitch_rw_t:file { write getattr read open execute execute_no_trans create unlink };\n>>> allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };\n>>> +allow openvswitch_t openvswitch_tmp_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>> +\n>>> +@begin_dpdk@\n>>> +allow openvswitch_t hugetlbfs_t:dir { write remove_name add_name lock read };\n>>> +allow openvswitch_t hugetlbfs_t:file { create unlink };\n>>> +allow openvswitch_t kernel_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>> +allow openvswitch_t self:tun_socket { relabelfrom relabelto create };\n>>\n>> Can you give an example why above rule is required? I believe it\n>> allows processes running under openvswitch_t type to change labels? I\n>> believe by having such rule the \"Mandatory\" access control becomes\n>> kinda like \"Discretionary\" in sense that process has now some\n>> discretion to alter SELinux policy.\n>\n> So, as you point out it allows openvswitch_t to relabel from / to on\n> tun_socket devices.\n>\n> Inline are the related AVC message records I have.\n>\n> ----------------------------- >8 --------------------------------\n> type=AVC msg=audit(1503426353.300:21402): avc: denied { relabelfrom } for pid=128134 comm=\"ovs-vswitchd\" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n> type=AVC msg=audit(1503426353.300:21402): avc: denied { relabelto } for pid=128134 comm=\"ovs-vswitchd\" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n> type=AVC msg=audit(1503426358.919:21406): avc: denied { create } for pid=128134 comm=\"ovs-vswitchd\" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n> ----------------------------- >8 --------------------------------\n>\n> I have to admit, I don't remember the exact details of what triggered\n> this particular AVC. When I get access to the testbed again, I can\n> recreate it and let you know (or post a follow up if required).\n\nWhile I could be wrong, I imagine that this rule is required if\novs-vswitchd process would:\n1. call chcon() system call itself; OR\n2. invoke a script or system utility that calls chcon().\n\nUnfortunately, a quick git-grep did not reveal where chcon could be\ninvoked from OVS code base.\n\nFor piece of mind I would prefer that I could assure that input\narguments are properly validated for this hypothetical chcon call.\n\n\n\n>\n>>> +allow openvswitch_t svirt_image_t:file { getattr read write };\n>>> +allow openvswitch_t tun_tap_device_t:chr_file { read write getattr open ioctl };\n>>> +allow openvswitch_t vfio_device_t:chr_file { read write open ioctl getattr };\n>>> +@end_dpdk@\n>>\n>> IIRC some time ago I mentioned that DPDK policy MAY be extended for\n>> DPDK via SELinux booleans\n>> [https://wiki.centos.org/TipsAndTricks/SelinuxBooleans]. I guess there\n>> was an issue why you did not want to pursue that path?\n>\n> It's one of administration. I've been trying to keep the overhead of\n> enabling dpdk support very low. Using a boolean is an additional step\n> out of the box. For most other projects (libvirt, etc.) it doesn't seem\n> like any additional out of the box configuration is needed to get a\n> working selinux configuration and have virtio (or other subsystems) work\n> with them, so I wanted to keep it that way.\n>\n> There's basically no technical issue I see either way, it's one of\n> preference. If you are really that concerned that you want a boolean, I\n> can do that, but it seemed inconvenient - and we can't accidentally open\n> the selinux policy too wide with non-dpdk enabled OvS since that is a\n> build-time restriction.\n>\n>> Other than that this patch looks good to me. I hope you tested it on\n>> RHEL and Fedora?\n>\n> Yes, RHEL and Fedora (but I didn't test on CentOS). Also, usually I\n> test with dpdk-enabled. I did try to keep the rules correct for both\n> cases, though.\n\nGreat. I am fine with series. Though, it wold be nice if you could\ntriage one more time why the relabeling rule is required.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"KI7J5sch\"; dkim-atps=neutral"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjty72QM1z9s7f\n\tfor ;\n\tFri, 1 Sep 2017 06:19:27 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 6FAD7BB3;\n\tThu, 31 Aug 2017 20:19:14 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id BC8DCB8A\n\tfor ; Thu, 31 Aug 2017 20:19:13 +0000 (UTC)","from mail-io0-f182.google.com (mail-io0-f182.google.com\n\t[209.85.223.182])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2B55212A\n\tfor ; Thu, 31 Aug 2017 20:19:13 +0000 (UTC)","by mail-io0-f182.google.com with SMTP id f99so5290731ioi.3\n\tfor ; Thu, 31 Aug 2017 13:19:13 -0700 (PDT)","by 10.107.8.138 with HTTP; Thu, 31 Aug 2017 13:19:11 -0700 (PDT)"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=vu8B812KnTk3yOqtYLP23KvL6iPI+tyRX8KSAj5L5wQ=;\n\tb=KI7J5schftgMLfZFeJ59wxpTDd0XOulwMM66v6bOPkBjHUyBnOsU65/W0nZ0WIjsS+\n\tCeCDiEiKEjgPriy7cyXhWZi31qF50xARX1+A8vVTYuN+7jfQ+FLBWkBwqx8+APzhsq89\n\tlmV5B1BBKpBSmMh8GUUZ/oV5ABNcdPZ5UnmkINjt7wZ11CxcENQl5UVdmiRf49DH499I\n\tiTQjV185KTGjUk6dOVJLzAHIgF1jcx0IlgaaY9X38m7m/iiWzUO5dwXXR9Y+uOQu0vzx\n\tvEkfuSSICUInb4izIsmYFigc9y3lEncrVl02Kw8Qr6Oe1a4R4H1aowRUIQzx+7E+Omeh\n\t9Wsg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=vu8B812KnTk3yOqtYLP23KvL6iPI+tyRX8KSAj5L5wQ=;\n\tb=aS5/+mJFoMCmqQVjDIgtfQ/MJhuBF20ehgy1fVf1ZfZ/Sl8GuO4zpQIRrV7AxxYjaz\n\tbKVIz7ixxhWfPLzY1mfdGZO2tTN9UkrH4aOUpqTIA3TtSFUHXoYK6B/bbIYQTQdZw0aE\n\ttwPai3ZWT+dZWL3TWU0svIAmyT1gH4ZNg70RujqZJkuTiidLxJCUY1TvyjgiOOs0nNeN\n\tEkGEnMEpEwFhQQH3/9OUFlPUz4zAp/evsTwr1TgTaokalA0/3nVjkkY1K/PhcBauagp9\n\t1vEJvSZRX5vSvOcDQTii8WsSgayEaklahTHHQhIPFgz0R06CAyMSC0k+MZN9RoP/JalD\n\tKKPQ==","X-Gm-Message-State":"AHPjjUhpZWwZewRGtN5AJsvs88q7fVLOWtzwLOhUbT9Gzr4lpiJaaBZf\n\tOmnjSmsU1OVy4f996/hfOG8GoTe1c5w/","X-Google-Smtp-Source":"ADKCNb4rjaNiDuJ2O2bg1WyQri4jv6HwVgQ8uBUispsk8UGNzf1nAPS+f1kHtV29A+8tsSaoCSpTsk0bZ8+fRtvImQw=","X-Received":"by 10.107.131.28 with SMTP id f28mr6018625iod.137.1504210752288; \n\tThu, 31 Aug 2017 13:19:12 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170830140035.22828-1-aconole@redhat.com>\n\t<20170830140035.22828-4-aconole@redhat.com>\n\t\n\t","From":"Ansis Atteka ","Date":"Thu, 31 Aug 2017 13:19:11 -0700","Message-ID":"","To":"Aaron Conole ","X-Spam-Status":"No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM\n\tautolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"\" ,\n\tFlavio Leitner , Ansis Atteka ","Subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1761344,"web_url":"http://patchwork.ozlabs.org/comment/1761344/","msgid":"","list_archive_url":null,"date":"2017-08-31T21:57:53","subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","submitter":{"id":67184,"url":"http://patchwork.ozlabs.org/api/people/67184/","name":"Aaron Conole","email":"aconole@redhat.com"},"content":"Ansis Atteka writes:\n\n> On 31 August 2017 at 11:58, Aaron Conole wrote:\n>> Hi Ansis,\n>>\n>> Thanks for the review!\n>>\n>> Ansis Atteka writes:\n>>\n>>> On 30 August 2017 at 07:00, Aaron Conole wrote:\n>>>> The selinux policy that exists in the repository did not specify access to\n>>>> all of the resources needed for Open vSwitch to properly function with\n>>>> an enforcing selinux policy. This update allows Open vSwitch to operate\n>>>> with selinux set to Enforcing mode, even while running as a non-root user.\n>>>>\n>>>> Acked-by: Flavio Leitner \n>>>> Signed-off-by: Aaron Conole \n>>>> Tested-by: Jean Hsiao \n>>>> ---\n>>>> selinux/openvswitch-custom.te.in | 40 +++++++++++++++++++++++++++++++++++++++-\n>>>> 1 file changed, 39 insertions(+), 1 deletion(-)\n>>>>\n>>>> diff --git a/selinux/openvswitch-custom.te.in b/selinux/openvswitch-custom.te.in\n>>>> index 47ddb56..66cb678 100644\n>>>> --- a/selinux/openvswitch-custom.te.in\n>>>> +++ b/selinux/openvswitch-custom.te.in\n>>>> @@ -2,15 +2,53 @@ module openvswitch-custom 1.0.1;\n>>>>\n>>>> require {\n>>>> type openvswitch_t;\n>>>> + type openvswitch_rw_t;\n>>>> type openvswitch_tmp_t;\n>>>> + type openvswitch_var_run_t;\n>>>> +\n>>>> type ifconfig_exec_t;\n>>>> type hostname_exec_t;\n>>>> + type tun_tap_device_t;\n>>>> +\n>>>> +@begin_dpdk@\n>>>> + type hugetlbfs_t;\n>>>> + type kernel_t;\n>>>> + type svirt_image_t;\n>>>> + type vfio_device_t;\n>>>> +@end_dpdk@\n>>>> +\n>>>> + class capability { dac_override audit_write };\n>>>> + class dir { write remove_name add_name lock read };\n>>>> + class file { write getattr read open execute execute_no_trans create unlink };\n>>>> + class netlink_audit_socket { create nlmsg_relay audit_write read write };\n>>>> class netlink_socket { setopt getopt create connect getattr write read };\n>>>> - class file { write getattr read open execute execute_no_trans };\n>>>> + class unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>>> +\n>>>> +@begin_dpdk@\n>>>> + class chr_file { write getattr read open ioctl };\n>>>> + class tun_socket { relabelfrom relabelto create };\n>>>> +@end_dpdk@\n>>>> }\n>>>>\n>>>> #============= openvswitch_t ==============\n>>>> +allow openvswitch_t self:capability { dac_override audit_write };\n>>>> +allow openvswitch_t self:netlink_audit_socket { create nlmsg_relay audit_write read write };\n>>>> allow openvswitch_t self:netlink_socket { setopt getopt create connect getattr write read };\n>>>> +\n>>>> allow openvswitch_t hostname_exec_t:file { read getattr open execute execute_no_trans };\n>>>> allow openvswitch_t ifconfig_exec_t:file { read getattr open execute execute_no_trans };\n>>>> +\n>>>> +allow openvswitch_t openvswitch_rw_t:dir { write remove_name add_name lock read };\n>>>> +allow openvswitch_t openvswitch_rw_t:file { write getattr read open execute execute_no_trans create unlink };\n>>>> allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };\n>>>> +allow openvswitch_t openvswitch_tmp_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>>> +\n>>>> +@begin_dpdk@\n>>>> +allow openvswitch_t hugetlbfs_t:dir { write remove_name add_name lock read };\n>>>> +allow openvswitch_t hugetlbfs_t:file { create unlink };\n>>>> +allow openvswitch_t kernel_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>>> +allow openvswitch_t self:tun_socket { relabelfrom relabelto create };\n>>>\n>>> Can you give an example why above rule is required? I believe it\n>>> allows processes running under openvswitch_t type to change labels? I\n>>> believe by having such rule the \"Mandatory\" access control becomes\n>>> kinda like \"Discretionary\" in sense that process has now some\n>>> discretion to alter SELinux policy.\n>>\n>> So, as you point out it allows openvswitch_t to relabel from / to on\n>> tun_socket devices.\n>>\n>> Inline are the related AVC message records I have.\n>>\n>> ----------------------------- >8 --------------------------------\n>> type=AVC msg=audit(1503426353.300:21402): avc: denied { relabelfrom\n>> } for pid=128134 comm=\"ovs-vswitchd\"\n>> scontext=system_u:system_r:openvswitch_t:s0\n>> tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n>> type=AVC msg=audit(1503426353.300:21402): avc: denied { relabelto }\n>> for pid=128134 comm=\"ovs-vswitchd\"\n>> scontext=system_u:system_r:openvswitch_t:s0\n>> tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n>> type=AVC msg=audit(1503426358.919:21406): avc: denied { create } for\n>> pid=128134 comm=\"ovs-vswitchd\"\n>> scontext=system_u:system_r:openvswitch_t:s0\n>> tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n>> ----------------------------- >8 --------------------------------\n>>\n>> I have to admit, I don't remember the exact details of what triggered\n>> this particular AVC. When I get access to the testbed again, I can\n>> recreate it and let you know (or post a follow up if required).\n>\n> While I could be wrong, I imagine that this rule is required if\n> ovs-vswitchd process would:\n> 1. call chcon() system call itself; OR\n> 2. invoke a script or system utility that calls chcon().\n>\n> Unfortunately, a quick git-grep did not reveal where chcon could be\n> invoked from OVS code base.\n>\n> For piece of mind I would prefer that I could assure that input\n> arguments are properly validated for this hypothetical chcon call.\n\nWithout having a test setup handy, I looked into the call chain.\nWhenever a process opens (read attaches to) a tun device, the LSM hook\nselinux_tun_dev_open() will get called. That call checks that the\nsubjective security ID of the current task has the RELABEL_FROM and\nRELABEL_TO permissions (see security/selinux/hooks.c:5067 and\nsecurity/selinux/hooks.c:6431).\n\nThis was added as part of ed6d76e4c32d (\"selinux: Support for the new\nTUN LSM hooks\"). The last sentence of the commit message explains:\n\n The _tun_dev_attach() is unique because it involves a\n domain attaching to an existing TUN device and its associated\n tun_socket object, an operation which does not exist with standard\n sockets and most closely resembles a relabel operation.\n\nThis is why the relabel to/from are required specifically for tun_socket\nobjects.\n\nLooking at the code, I don't see where that is happening (possibly in\nnetdev-linux when a tap is created ... except that I didn't create a tap\ndevice in any of my tests). It's possibly a label given to a dpdk\nspecific communication channel (which seems likely, since they do many\ndifferent types of internal pipes for communication). I thought it\nmight be triggered if I used a tap device, which does open\n\"/dev/net/tun.\"\n\nHowever, trying on my local fedora setup (f25), I can reproduce the\nvarious tun_tap_device_t create/open/read/write/ioctl errors, so those\nprobably should be moved out of the dpdk-specific area in v3 (or if this\nis already applied I can write a quick follow up to address it). But I\ncannot trigger the tun_socket errors, thus far. So I'll keep them as\ndpdk-only.\n\n>\n>\n>>\n>>>> +allow openvswitch_t svirt_image_t:file { getattr read write };\n>>>> +allow openvswitch_t tun_tap_device_t:chr_file { read write getattr open ioctl };\n>>>> +allow openvswitch_t vfio_device_t:chr_file { read write open ioctl getattr };\n>>>> +@end_dpdk@\n>>>\n>>> IIRC some time ago I mentioned that DPDK policy MAY be extended for\n>>> DPDK via SELinux booleans\n>>> [https://wiki.centos.org/TipsAndTricks/SelinuxBooleans]. I guess there\n>>> was an issue why you did not want to pursue that path?\n>>\n>> It's one of administration. I've been trying to keep the overhead of\n>> enabling dpdk support very low. Using a boolean is an additional step\n>> out of the box. For most other projects (libvirt, etc.) it doesn't seem\n>> like any additional out of the box configuration is needed to get a\n>> working selinux configuration and have virtio (or other subsystems) work\n>> with them, so I wanted to keep it that way.\n>>\n>> There's basically no technical issue I see either way, it's one of\n>> preference. If you are really that concerned that you want a boolean, I\n>> can do that, but it seemed inconvenient - and we can't accidentally open\n>> the selinux policy too wide with non-dpdk enabled OvS since that is a\n>> build-time restriction.\n>>\n>>> Other than that this patch looks good to me. I hope you tested it on\n>>> RHEL and Fedora?\n>>\n>> Yes, RHEL and Fedora (but I didn't test on CentOS). Also, usually I\n>> test with dpdk-enabled. I did try to keep the rules correct for both\n>> cases, though.\n>\n> Great. I am fine with series. Though, it wold be nice if you could\n> triage one more time why the relabeling rule is required.\n\nHopefully the above explains. Let me know if I should post v3 (and\nmaybe have your Acked-by?), or if this is applied and a follow up patch\nis needed.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=aconole@redhat.com"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjx7s304Wz9s81\n\tfor ;\n\tFri, 1 Sep 2017 07:58:01 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 47C74C76;\n\tThu, 31 Aug 2017 21:57:58 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id D7213A67\n\tfor ; Thu, 31 Aug 2017 21:57:56 +0000 (UTC)","from mx1.redhat.com (mx1.redhat.com [209.132.183.28])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16AC11E5\n\tfor ; Thu, 31 Aug 2017 21:57:56 +0000 (UTC)","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 7E578356CE;\n\tThu, 31 Aug 2017 21:57:55 +0000 (UTC)","from dhcp-25-97.bos.redhat.com (unknown [10.18.25.172])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id CEA935F930;\n\tThu, 31 Aug 2017 21:57:54 +0000 (UTC)"],"X-Greylist":["domain auto-whitelisted by SQLgrey-1.7.6","Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.30]);\n\tThu, 31 Aug 2017 21:57:55 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 7E578356CE","From":"Aaron Conole ","To":"Ansis Atteka ","References":"<20170830140035.22828-1-aconole@redhat.com>\n\t<20170830140035.22828-4-aconole@redhat.com>\n\t\n\t\n\t","Date":"Thu, 31 Aug 2017 17:57:53 -0400","In-Reply-To":"\n\t(Ansis Atteka's message of \"Thu, 31 Aug 2017 13:19:11 -0700\")","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.79 on 10.5.11.14","X-Spam-Status":"No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,\n\tRP_MATCHES_RCVD autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"\" ,\n\tFlavio Leitner , Ansis Atteka ","Subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1761361,"web_url":"http://patchwork.ozlabs.org/comment/1761361/","msgid":"","list_archive_url":null,"date":"2017-08-31T22:59:00","subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","submitter":{"id":17389,"url":"http://patchwork.ozlabs.org/api/people/17389/","name":"Ansis","email":"ansisatteka@gmail.com"},"content":"On 31 August 2017 at 14:57, Aaron Conole wrote:\n> Ansis Atteka writes:\n>\n>> On 31 August 2017 at 11:58, Aaron Conole wrote:\n>>> Hi Ansis,\n>>>\n>>> Thanks for the review!\n>>>\n>>> Ansis Atteka writes:\n>>>\n>>>> On 30 August 2017 at 07:00, Aaron Conole wrote:\n>>>>> The selinux policy that exists in the repository did not specify access to\n>>>>> all of the resources needed for Open vSwitch to properly function with\n>>>>> an enforcing selinux policy. This update allows Open vSwitch to operate\n>>>>> with selinux set to Enforcing mode, even while running as a non-root user.\n>>>>>\n>>>>> Acked-by: Flavio Leitner \n>>>>> Signed-off-by: Aaron Conole \n>>>>> Tested-by: Jean Hsiao \n>>>>> ---\n>>>>> selinux/openvswitch-custom.te.in | 40 +++++++++++++++++++++++++++++++++++++++-\n>>>>> 1 file changed, 39 insertions(+), 1 deletion(-)\n>>>>>\n>>>>> diff --git a/selinux/openvswitch-custom.te.in b/selinux/openvswitch-custom.te.in\n>>>>> index 47ddb56..66cb678 100644\n>>>>> --- a/selinux/openvswitch-custom.te.in\n>>>>> +++ b/selinux/openvswitch-custom.te.in\n>>>>> @@ -2,15 +2,53 @@ module openvswitch-custom 1.0.1;\n>>>>>\n>>>>> require {\n>>>>> type openvswitch_t;\n>>>>> + type openvswitch_rw_t;\n>>>>> type openvswitch_tmp_t;\n>>>>> + type openvswitch_var_run_t;\n>>>>> +\n>>>>> type ifconfig_exec_t;\n>>>>> type hostname_exec_t;\n>>>>> + type tun_tap_device_t;\n>>>>> +\n>>>>> +@begin_dpdk@\n>>>>> + type hugetlbfs_t;\n>>>>> + type kernel_t;\n>>>>> + type svirt_image_t;\n>>>>> + type vfio_device_t;\n>>>>> +@end_dpdk@\n>>>>> +\n>>>>> + class capability { dac_override audit_write };\n>>>>> + class dir { write remove_name add_name lock read };\n>>>>> + class file { write getattr read open execute execute_no_trans create unlink };\n>>>>> + class netlink_audit_socket { create nlmsg_relay audit_write read write };\n>>>>> class netlink_socket { setopt getopt create connect getattr write read };\n>>>>> - class file { write getattr read open execute execute_no_trans };\n>>>>> + class unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>>>> +\n>>>>> +@begin_dpdk@\n>>>>> + class chr_file { write getattr read open ioctl };\n>>>>> + class tun_socket { relabelfrom relabelto create };\n>>>>> +@end_dpdk@\n>>>>> }\n>>>>>\n>>>>> #============= openvswitch_t ==============\n>>>>> +allow openvswitch_t self:capability { dac_override audit_write };\n>>>>> +allow openvswitch_t self:netlink_audit_socket { create nlmsg_relay audit_write read write };\n>>>>> allow openvswitch_t self:netlink_socket { setopt getopt create connect getattr write read };\n>>>>> +\n>>>>> allow openvswitch_t hostname_exec_t:file { read getattr open execute execute_no_trans };\n>>>>> allow openvswitch_t ifconfig_exec_t:file { read getattr open execute execute_no_trans };\n>>>>> +\n>>>>> +allow openvswitch_t openvswitch_rw_t:dir { write remove_name add_name lock read };\n>>>>> +allow openvswitch_t openvswitch_rw_t:file { write getattr read open execute execute_no_trans create unlink };\n>>>>> allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };\n>>>>> +allow openvswitch_t openvswitch_tmp_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>>>> +\n>>>>> +@begin_dpdk@\n>>>>> +allow openvswitch_t hugetlbfs_t:dir { write remove_name add_name lock read };\n>>>>> +allow openvswitch_t hugetlbfs_t:file { create unlink };\n>>>>> +allow openvswitch_t kernel_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>>>> +allow openvswitch_t self:tun_socket { relabelfrom relabelto create };\n>>>>\n>>>> Can you give an example why above rule is required? I believe it\n>>>> allows processes running under openvswitch_t type to change labels? I\n>>>> believe by having such rule the \"Mandatory\" access control becomes\n>>>> kinda like \"Discretionary\" in sense that process has now some\n>>>> discretion to alter SELinux policy.\n>>>\n>>> So, as you point out it allows openvswitch_t to relabel from / to on\n>>> tun_socket devices.\n>>>\n>>> Inline are the related AVC message records I have.\n>>>\n>>> ----------------------------- >8 --------------------------------\n>>> type=AVC msg=audit(1503426353.300:21402): avc: denied { relabelfrom\n>>> } for pid=128134 comm=\"ovs-vswitchd\"\n>>> scontext=system_u:system_r:openvswitch_t:s0\n>>> tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n>>> type=AVC msg=audit(1503426353.300:21402): avc: denied { relabelto }\n>>> for pid=128134 comm=\"ovs-vswitchd\"\n>>> scontext=system_u:system_r:openvswitch_t:s0\n>>> tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n>>> type=AVC msg=audit(1503426358.919:21406): avc: denied { create } for\n>>> pid=128134 comm=\"ovs-vswitchd\"\n>>> scontext=system_u:system_r:openvswitch_t:s0\n>>> tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n>>> ----------------------------- >8 --------------------------------\n>>>\n>>> I have to admit, I don't remember the exact details of what triggered\n>>> this particular AVC. When I get access to the testbed again, I can\n>>> recreate it and let you know (or post a follow up if required).\n>>\n>> While I could be wrong, I imagine that this rule is required if\n>> ovs-vswitchd process would:\n>> 1. call chcon() system call itself; OR\n>> 2. invoke a script or system utility that calls chcon().\n>>\n>> Unfortunately, a quick git-grep did not reveal where chcon could be\n>> invoked from OVS code base.\n>>\n>> For piece of mind I would prefer that I could assure that input\n>> arguments are properly validated for this hypothetical chcon call.\n>\n> Without having a test setup handy, I looked into the call chain.\n> Whenever a process opens (read attaches to) a tun device, the LSM hook\n> selinux_tun_dev_open() will get called. That call checks that the\n> subjective security ID of the current task has the RELABEL_FROM and\n> RELABEL_TO permissions (see security/selinux/hooks.c:5067 and\n> security/selinux/hooks.c:6431).\n>\n> This was added as part of ed6d76e4c32d (\"selinux: Support for the new\n> TUN LSM hooks\"). The last sentence of the commit message explains:\n>\n> The _tun_dev_attach() is unique because it involves a\n> domain attaching to an existing TUN device and its associated\n> tun_socket object, an operation which does not exist with standard\n> sockets and most closely resembles a relabel operation.\n>\n> This is why the relabel to/from are required specifically for tun_socket\n> objects.\n\nThanks for looking that up. I think your explanations sounds very plausible.\n\n>\n> Looking at the code, I don't see where that is happening (possibly in\n> netdev-linux when a tap is created ... except that I didn't create a tap\n> device in any of my tests). It's possibly a label given to a dpdk\n> specific communication channel (which seems likely, since they do many\n> different types of internal pipes for communication). I thought it\n> might be triggered if I used a tap device, which does open\n> \"/dev/net/tun.\"\n>\n> However, trying on my local fedora setup (f25), I can reproduce the\n> various tun_tap_device_t create/open/read/write/ioctl errors, so those\n> probably should be moved out of the dpdk-specific area in v3 (or if this\n> is already applied I can write a quick follow up to address it). But I\n> cannot trigger the tun_socket errors, thus far. So I'll keep them as\n> dpdk-only.\n>\n>>\n>>\n>>>\n>>>>> +allow openvswitch_t svirt_image_t:file { getattr read write };\n>>>>> +allow openvswitch_t tun_tap_device_t:chr_file { read write getattr open ioctl };\n>>>>> +allow openvswitch_t vfio_device_t:chr_file { read write open ioctl getattr };\n>>>>> +@end_dpdk@\n>>>>\n>>>> IIRC some time ago I mentioned that DPDK policy MAY be extended for\n>>>> DPDK via SELinux booleans\n>>>> [https://wiki.centos.org/TipsAndTricks/SelinuxBooleans]. I guess there\n>>>> was an issue why you did not want to pursue that path?\n>>>\n>>> It's one of administration. I've been trying to keep the overhead of\n>>> enabling dpdk support very low. Using a boolean is an additional step\n>>> out of the box. For most other projects (libvirt, etc.) it doesn't seem\n>>> like any additional out of the box configuration is needed to get a\n>>> working selinux configuration and have virtio (or other subsystems) work\n>>> with them, so I wanted to keep it that way.\n>>>\n>>> There's basically no technical issue I see either way, it's one of\n>>> preference. If you are really that concerned that you want a boolean, I\n>>> can do that, but it seemed inconvenient - and we can't accidentally open\n>>> the selinux policy too wide with non-dpdk enabled OvS since that is a\n>>> build-time restriction.\n>>>\n>>>> Other than that this patch looks good to me. I hope you tested it on\n>>>> RHEL and Fedora?\n>>>\n>>> Yes, RHEL and Fedora (but I didn't test on CentOS). Also, usually I\n>>> test with dpdk-enabled. I did try to keep the rules correct for both\n>>> cases, though.\n>>\n>> Great. I am fine with series. Though, it wold be nice if you could\n>> triage one more time why the relabeling rule is required.\n>\n> Hopefully the above explains. Let me know if I should post v3 (and\n> maybe have your Acked-by?), or if this is applied and a follow up patch\n> is needed.\n\nI have not applied your patch yet. Feel free to send v3 and then I\nwill apply your patches.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"Kfl98IN6\"; dkim-atps=neutral"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjyVM6p3Vz9s83\n\tfor ;\n\tFri, 1 Sep 2017 08:59:07 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id B8206D50;\n\tThu, 31 Aug 2017 22:59:03 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 05EFED40\n\tfor ; Thu, 31 Aug 2017 22:59:03 +0000 (UTC)","from mail-io0-f179.google.com (mail-io0-f179.google.com\n\t[209.85.223.179])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2F85B79\n\tfor ; Thu, 31 Aug 2017 22:59:02 +0000 (UTC)","by mail-io0-f179.google.com with SMTP id b2so7524915iof.0\n\tfor ; Thu, 31 Aug 2017 15:59:02 -0700 (PDT)","by 10.107.8.138 with HTTP; Thu, 31 Aug 2017 15:59:00 -0700 (PDT)"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=+HHj+D35I7pBNYBD/bSazFx0vnvgPZK7P97+ujMPmw0=;\n\tb=Kfl98IN65Oo5dX1izR+Vy2JxWdEh+4X+kywJWMBFmoe66kjliwp7TpBe8jN56H62Rr\n\tYdllw/uUCZWhNZJcDDR80QP6YzWw6lHlRGwJNgH2gtjIx6MyphPiuDz2uKcD3iKunYRB\n\tL4qXaMqtB11ar+s9hOi2JhB+0BUIgSeUmRGnH3ReR4S32ei5kQyTsB5OG4Niamuk9deF\n\tnyfuWfrcoyVbdrh3/yDPdpkqe8rvdkdGqrY7gZsU/ohp9lCjz/v+3RcsAvuM0x5Q+8PB\n\tcOheicwjR4Mpfb1GAncgzQ3Nn68fL0PwXn00+1TaQI2ZAfuBdt56u2NZOhy4LVh010WT\n\ttVjw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=+HHj+D35I7pBNYBD/bSazFx0vnvgPZK7P97+ujMPmw0=;\n\tb=HDKQDKz3Xetk1ZeKpaFzVid8WWBYnaFsOR4PL8BEZp1hb7jnqTGSWAINAkD04s/6/q\n\tr+kA3cmTt4ul8LBeSMPi9zeEVhe9eOAgH+Q0Eub/X0C8oE+ieaGTEW9t5/PpYKH3rwn3\n\tNj0eF9intxTOf+Vmrs37s0rk80vgV+VeqfMShXqoEFi4Ltn1t7vmQINwGPuUaDxJY9qF\n\t3u525hUVYGc2N14AVpPKrXq82AoWjBokR+cgTnZdVemymueNZzuW0EoQA5RmY6PoQE2I\n\tpK8oD4hpT7WvGHiO3AFx8t4y3UzisxbnyW16R1lFGT1/NOzk9Hb7quey/aO+E3hgsXwK\n\thoRw==","X-Gm-Message-State":"AHPjjUg4BhTChAsMXVl1mqyGImKUVoucYO4TW48Ve6HX0fAnol3bBp3f\n\t3lc9pEL2D1iOloRxnZANYbwXKdDFzQ==","X-Google-Smtp-Source":"ADKCNb5xlDyKpzGqciMW2P9F3Zs/nQdIgLwy2xqQ91a9O5Oys7esCsXWHwBTwAsgp0dEzS31hXuiRL+I6jUx9U4aSP8=","X-Received":"by 10.36.124.141 with SMTP id a135mr259449itd.179.1504220341231; \n\tThu, 31 Aug 2017 15:59:01 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170830140035.22828-1-aconole@redhat.com>\n\t<20170830140035.22828-4-aconole@redhat.com>\n\t\n\t\n\t\n\t","From":"Ansis Atteka ","Date":"Thu, 31 Aug 2017 15:59:00 -0700","Message-ID":"","To":"Aaron Conole ","X-Spam-Status":"No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM\n\tautolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"\" ,\n\tFlavio Leitner , Ansis Atteka ","Subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1761375,"web_url":"http://patchwork.ozlabs.org/comment/1761375/","msgid":"","list_archive_url":null,"date":"2017-08-31T23:25:34","subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","submitter":{"id":67184,"url":"http://patchwork.ozlabs.org/api/people/67184/","name":"Aaron Conole","email":"aconole@redhat.com"},"content":"Ansis Atteka writes:\n\n> On 31 August 2017 at 14:57, Aaron Conole wrote:\n>> Ansis Atteka writes:\n>>\n>>> On 31 August 2017 at 11:58, Aaron Conole wrote:\n>>>> Hi Ansis,\n>>>>\n>>>> Thanks for the review!\n>>>>\n>>>> Ansis Atteka writes:\n>>>>\n>>>>> On 30 August 2017 at 07:00, Aaron Conole wrote:\n>>>>>> The selinux policy that exists in the repository did not specify access to\n>>>>>> all of the resources needed for Open vSwitch to properly function with\n>>>>>> an enforcing selinux policy. This update allows Open vSwitch to operate\n>>>>>> with selinux set to Enforcing mode, even while running as a non-root user.\n>>>>>>\n>>>>>> Acked-by: Flavio Leitner \n>>>>>> Signed-off-by: Aaron Conole \n>>>>>> Tested-by: Jean Hsiao \n>>>>>> ---\n>>>>>> selinux/openvswitch-custom.te.in | 40 +++++++++++++++++++++++++++++++++++++++-\n>>>>>> 1 file changed, 39 insertions(+), 1 deletion(-)\n>>>>>>\n>>>>>> diff --git a/selinux/openvswitch-custom.te.in b/selinux/openvswitch-custom.te.in\n>>>>>> index 47ddb56..66cb678 100644\n>>>>>> --- a/selinux/openvswitch-custom.te.in\n>>>>>> +++ b/selinux/openvswitch-custom.te.in\n>>>>>> @@ -2,15 +2,53 @@ module openvswitch-custom 1.0.1;\n>>>>>>\n>>>>>> require {\n>>>>>> type openvswitch_t;\n>>>>>> + type openvswitch_rw_t;\n>>>>>> type openvswitch_tmp_t;\n>>>>>> + type openvswitch_var_run_t;\n>>>>>> +\n>>>>>> type ifconfig_exec_t;\n>>>>>> type hostname_exec_t;\n>>>>>> + type tun_tap_device_t;\n>>>>>> +\n>>>>>> +@begin_dpdk@\n>>>>>> + type hugetlbfs_t;\n>>>>>> + type kernel_t;\n>>>>>> + type svirt_image_t;\n>>>>>> + type vfio_device_t;\n>>>>>> +@end_dpdk@\n>>>>>> +\n>>>>>> + class capability { dac_override audit_write };\n>>>>>> + class dir { write remove_name add_name lock read };\n>>>>>> + class file { write getattr read open execute execute_no_trans create unlink };\n>>>>>> + class netlink_audit_socket { create nlmsg_relay audit_write read write };\n>>>>>> class netlink_socket { setopt getopt create connect getattr write read };\n>>>>>> - class file { write getattr read open execute execute_no_trans };\n>>>>>> + class unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>>>>> +\n>>>>>> +@begin_dpdk@\n>>>>>> + class chr_file { write getattr read open ioctl };\n>>>>>> + class tun_socket { relabelfrom relabelto create };\n>>>>>> +@end_dpdk@\n>>>>>> }\n>>>>>>\n>>>>>> #============= openvswitch_t ==============\n>>>>>> +allow openvswitch_t self:capability { dac_override audit_write };\n>>>>>> +allow openvswitch_t self:netlink_audit_socket { create nlmsg_relay audit_write read write };\n>>>>>> allow openvswitch_t self:netlink_socket { setopt getopt create connect getattr write read };\n>>>>>> +\n>>>>>> allow openvswitch_t hostname_exec_t:file { read getattr open execute execute_no_trans };\n>>>>>> allow openvswitch_t ifconfig_exec_t:file { read getattr open execute execute_no_trans };\n>>>>>> +\n>>>>>> +allow openvswitch_t openvswitch_rw_t:dir { write remove_name add_name lock read };\n>>>>>> +allow openvswitch_t openvswitch_rw_t:file { write getattr read open execute execute_no_trans create unlink };\n>>>>>> allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };\n>>>>>> +allow openvswitch_t openvswitch_tmp_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>>>>> +\n>>>>>> +@begin_dpdk@\n>>>>>> +allow openvswitch_t hugetlbfs_t:dir { write remove_name add_name lock read };\n>>>>>> +allow openvswitch_t hugetlbfs_t:file { create unlink };\n>>>>>> +allow openvswitch_t kernel_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };\n>>>>>> +allow openvswitch_t self:tun_socket { relabelfrom relabelto create };\n>>>>>\n>>>>> Can you give an example why above rule is required? I believe it\n>>>>> allows processes running under openvswitch_t type to change labels? I\n>>>>> believe by having such rule the \"Mandatory\" access control becomes\n>>>>> kinda like \"Discretionary\" in sense that process has now some\n>>>>> discretion to alter SELinux policy.\n>>>>\n>>>> So, as you point out it allows openvswitch_t to relabel from / to on\n>>>> tun_socket devices.\n>>>>\n>>>> Inline are the related AVC message records I have.\n>>>>\n>>>> ----------------------------- >8 --------------------------------\n>>>> type=AVC msg=audit(1503426353.300:21402): avc: denied { relabelfrom\n>>>> } for pid=128134 comm=\"ovs-vswitchd\"\n>>>> scontext=system_u:system_r:openvswitch_t:s0\n>>>> tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n>>>> type=AVC msg=audit(1503426353.300:21402): avc: denied { relabelto }\n>>>> for pid=128134 comm=\"ovs-vswitchd\"\n>>>> scontext=system_u:system_r:openvswitch_t:s0\n>>>> tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n>>>> type=AVC msg=audit(1503426358.919:21406): avc: denied { create } for\n>>>> pid=128134 comm=\"ovs-vswitchd\"\n>>>> scontext=system_u:system_r:openvswitch_t:s0\n>>>> tcontext=system_u:system_r:openvswitch_t:s0 tclass=tun_socket\n>>>> ----------------------------- >8 --------------------------------\n>>>>\n>>>> I have to admit, I don't remember the exact details of what triggered\n>>>> this particular AVC. When I get access to the testbed again, I can\n>>>> recreate it and let you know (or post a follow up if required).\n>>>\n>>> While I could be wrong, I imagine that this rule is required if\n>>> ovs-vswitchd process would:\n>>> 1. call chcon() system call itself; OR\n>>> 2. invoke a script or system utility that calls chcon().\n>>>\n>>> Unfortunately, a quick git-grep did not reveal where chcon could be\n>>> invoked from OVS code base.\n>>>\n>>> For piece of mind I would prefer that I could assure that input\n>>> arguments are properly validated for this hypothetical chcon call.\n>>\n>> Without having a test setup handy, I looked into the call chain.\n>> Whenever a process opens (read attaches to) a tun device, the LSM hook\n>> selinux_tun_dev_open() will get called. That call checks that the\n>> subjective security ID of the current task has the RELABEL_FROM and\n>> RELABEL_TO permissions (see security/selinux/hooks.c:5067 and\n>> security/selinux/hooks.c:6431).\n>>\n>> This was added as part of ed6d76e4c32d (\"selinux: Support for the new\n>> TUN LSM hooks\"). The last sentence of the commit message explains:\n>>\n>> The _tun_dev_attach() is unique because it involves a\n>> domain attaching to an existing TUN device and its associated\n>> tun_socket object, an operation which does not exist with standard\n>> sockets and most closely resembles a relabel operation.\n>>\n>> This is why the relabel to/from are required specifically for tun_socket\n>> objects.\n>\n> Thanks for looking that up. I think your explanations sounds very plausible.\n>\n>>\n>> Looking at the code, I don't see where that is happening (possibly in\n>> netdev-linux when a tap is created ... except that I didn't create a tap\n>> device in any of my tests). It's possibly a label given to a dpdk\n>> specific communication channel (which seems likely, since they do many\n>> different types of internal pipes for communication). I thought it\n>> might be triggered if I used a tap device, which does open\n>> \"/dev/net/tun.\"\n>>\n>> However, trying on my local fedora setup (f25), I can reproduce the\n>> various tun_tap_device_t create/open/read/write/ioctl errors, so those\n>> probably should be moved out of the dpdk-specific area in v3 (or if this\n>> is already applied I can write a quick follow up to address it). But I\n>> cannot trigger the tun_socket errors, thus far. So I'll keep them as\n>> dpdk-only.\n>>\n>>>\n>>>\n>>>>\n>>>>>> +allow openvswitch_t svirt_image_t:file { getattr read write };\n>>>>>> +allow openvswitch_t tun_tap_device_t:chr_file { read write\n>>>>>> getattr open ioctl };\n>>>>>> +allow openvswitch_t vfio_device_t:chr_file { read write open\n>>>>>> ioctl getattr };\n>>>>>> +@end_dpdk@\n>>>>>\n>>>>> IIRC some time ago I mentioned that DPDK policy MAY be extended for\n>>>>> DPDK via SELinux booleans\n>>>>> [https://wiki.centos.org/TipsAndTricks/SelinuxBooleans]. I guess there\n>>>>> was an issue why you did not want to pursue that path?\n>>>>\n>>>> It's one of administration. I've been trying to keep the overhead of\n>>>> enabling dpdk support very low. Using a boolean is an additional step\n>>>> out of the box. For most other projects (libvirt, etc.) it doesn't seem\n>>>> like any additional out of the box configuration is needed to get a\n>>>> working selinux configuration and have virtio (or other subsystems) work\n>>>> with them, so I wanted to keep it that way.\n>>>>\n>>>> There's basically no technical issue I see either way, it's one of\n>>>> preference. If you are really that concerned that you want a boolean, I\n>>>> can do that, but it seemed inconvenient - and we can't accidentally open\n>>>> the selinux policy too wide with non-dpdk enabled OvS since that is a\n>>>> build-time restriction.\n>>>>\n>>>>> Other than that this patch looks good to me. I hope you tested it on\n>>>>> RHEL and Fedora?\n>>>>\n>>>> Yes, RHEL and Fedora (but I didn't test on CentOS). Also, usually I\n>>>> test with dpdk-enabled. I did try to keep the rules correct for both\n>>>> cases, though.\n>>>\n>>> Great. I am fine with series. Though, it wold be nice if you could\n>>> triage one more time why the relabeling rule is required.\n>>\n>> Hopefully the above explains. Let me know if I should post v3 (and\n>> maybe have your Acked-by?), or if this is applied and a follow up patch\n>> is needed.\n>\n> I have not applied your patch yet. Feel free to send v3 and then I\n> will apply your patches.\n\nAwesome. Thanks for all your help! I've CC'd you in the new version.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=aconole@redhat.com"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjz520bFdz9s7p\n\tfor ;\n\tFri, 1 Sep 2017 09:25:42 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id CF3F7DB6;\n\tThu, 31 Aug 2017 23:25:38 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id AA81CD2A\n\tfor ; Thu, 31 Aug 2017 23:25:37 +0000 (UTC)","from mx1.redhat.com (mx1.redhat.com [209.132.183.28])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB39679\n\tfor ; Thu, 31 Aug 2017 23:25:36 +0000 (UTC)","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 5343A6147C;\n\tThu, 31 Aug 2017 23:25:36 +0000 (UTC)","from dhcp-25-97.bos.redhat.com (ovpn-121-92.rdu2.redhat.com\n\t[10.10.121.92])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 9C4CE5D6A2;\n\tThu, 31 Aug 2017 23:25:35 +0000 (UTC)"],"X-Greylist":["domain auto-whitelisted by SQLgrey-1.7.6","Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.39]);\n\tThu, 31 Aug 2017 23:25:36 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 5343A6147C","From":"Aaron Conole ","To":"Ansis Atteka ","References":"<20170830140035.22828-1-aconole@redhat.com>\n\t<20170830140035.22828-4-aconole@redhat.com>\n\t\n\t\n\t\n\t\n\t","Date":"Thu, 31 Aug 2017 19:25:34 -0400","In-Reply-To":"\n\t(Ansis Atteka's message of \"Thu, 31 Aug 2017 15:59:00 -0700\")","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.79 on 10.5.11.15","X-Spam-Status":"No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,\n\tRP_MATCHES_RCVD autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"\" ,\n\tFlavio Leitner , Ansis Atteka ","Subject":"Re: [ovs-dev] [PATCH v2 3/3] selinux: update policy to reflect\n\tnon-root and dpdk support","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}}]