From patchwork Thu Sep 17 18:27:07 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Russell Bryant X-Patchwork-Id: 518992 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from archives.nicira.com (unknown [IPv6:2600:3c00::f03c:91ff:fe6e:bdf7]) by ozlabs.org (Postfix) with ESMTP id CF78814147D for ; Fri, 18 Sep 2015 04:27:41 +1000 (AEST) Received: from archives.nicira.com (localhost [127.0.0.1]) by archives.nicira.com (Postfix) with ESMTP id 6F5EA10AD1; Thu, 17 Sep 2015 11:27:40 -0700 (PDT) X-Original-To: dev@openvswitch.org Delivered-To: dev@openvswitch.org Received: from mx1e3.cudamail.com (mx1.cudamail.com [69.90.118.67]) by archives.nicira.com (Postfix) with ESMTPS id 57BDB1077A for ; Thu, 17 Sep 2015 11:27:38 -0700 (PDT) Received: from bar2.cudamail.com (localhost [127.0.0.1]) by mx1e3.cudamail.com (Postfix) with ESMTPS id 8FCB24200BD for ; Thu, 17 Sep 2015 12:27:37 -0600 (MDT) X-ASG-Debug-ID: 1442514434-03dc537fe31d07b0001-byXFYA Received: from mx1-pf2.cudamail.com ([192.168.24.2]) by bar2.cudamail.com with ESMTP id EKAXbXsDkRy6aqv8 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Sep 2015 12:27:14 -0600 (MDT) X-Barracuda-Envelope-From: rbryant@redhat.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.24.2 Received: from unknown (HELO mx1.redhat.com) (209.132.183.28) by mx1-pf2.cudamail.com with ESMTPS (DHE-RSA-AES256-SHA encrypted); 17 Sep 2015 18:27:13 -0000 Received-SPF: error (mx1-pf2.cudamail.com: error in processing during lookup of redhat.com: DNS problem) X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-Barracuda-RBL-IP: 209.132.183.28 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 9782C3B3C7; Thu, 17 Sep 2015 18:27:12 +0000 (UTC) Received: from x1c.redhat.com (ovpn-112-95.phx2.redhat.com [10.3.112.95]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8HIR8Iv030725; Thu, 17 Sep 2015 14:27:09 -0400 X-CudaMail-Envelope-Sender: rbryant@redhat.com From: Russell Bryant To: dev@openvswitch.org X-CudaMail-MID: CM-E2-916070477 X-CudaMail-DTE: 091715 X-CudaMail-Originating-IP: 209.132.183.28 Date: Thu, 17 Sep 2015 14:27:07 -0400 X-ASG-Orig-Subj: [##CM-E2-916070477##][PATCH] ovn: Update TODO with some notes on security. Message-Id: <1442514427-19930-1-git-send-email-rbryant@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-GBUdb-Analysis: 0, 209.132.183.28, Ugly c=0.226425 p=-0.111111 Source Normal X-MessageSniffer-Rules: 0-0-0-7076-c X-Barracuda-Connect: UNKNOWN[192.168.24.2] X-Barracuda-Start-Time: 1442514434 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://web.cudamail.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at cudamail.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=3.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_SC5_MJ1963, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22641 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 Subject: [ovs-dev] [PATCH] ovn: Update TODO with some notes on security. X-BeenThere: dev@openvswitch.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dev-bounces@openvswitch.org Sender: "dev" The impact of the compromise of a chassis running ovn-controller came up in a discussion with the developers of a system that could potentially use OVN. Capture some notes on this issue as a todo item. Signed-off-by: Russell Bryant --- ovn/TODO | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/ovn/TODO b/ovn/TODO index 6f625ce..a48251f 100644 --- a/ovn/TODO +++ b/ovn/TODO @@ -6,6 +6,42 @@ Can probably get this from Open_vSwitch database. +** Security + +*** Limiting the impact of a compromised chassis. + + Every instance of ovn-controller has the same full access to the central + OVN_Southbound database. This means that a compromised chassis can + interfere with the normal operation of the rest of the deployment. Some + specific examples include writing to the logical flow table to alter + traffic handling or updating the port binding table to claim ports that are + actually present on a different chassis. In practice, the compromised host + would be fighting against ovn-northd and other instances of ovn-controller + that would be trying to restore the correct state. The impact could include + at least temporarily redirecting traffic (so the compromised host could + receive traffic that it shouldn't) and potentially a more general denial of + service. + + There are different potential improvements to this area. The first would be + to add some sort of ACL scheme to ovsdb-server. A proposal for this should + first include an ACL scheme for ovn-controller. An example policy would + be to make Logical_Flow read-only. Table-level control is needed, but is + not enough. For example, ovn-controller must be able to update the Chassis + and Encap tables, but should only be able to modify the rows associated with + that chassis and no others. + + A more complex example is the Port_Binding table. Currently, ovn-controller + is the source of truth of where a port is located. There seems to be no + policy that can prevent malicious behavior of a compromised host with this + table. + + An alternative scheme for port bindings would be to provide an optional mode + where an external entity controls port bindings and make them read-only to + ovn-controller. This is actually how OpenStack works today, for example. + The part of OpenStack that manages VMs (Nova) tells the networking component + (Neutron) where a port will be located, as opposed to the networking + component discovering it. + * ovsdb-server ovsdb-server should have adequate features for OVN but it probably @@ -100,4 +136,4 @@ Both ovn-controller and ovn-contorller-vtep should use BFD to monitor the tunnel liveness. Both ovs-vswitchd schema and - VTEP schema supports BFD. \ No newline at end of file + VTEP schema supports BFD.