diff mbox

[ovs-dev] ovn: Update TODO with some notes on security.

Message ID 1442514427-19930-1-git-send-email-rbryant@redhat.com
State Accepted
Headers show

Commit Message

Russell Bryant Sept. 17, 2015, 6:27 p.m. UTC 
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 <rbryant@redhat.com>
---
 ovn/TODO | 38 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

Comments

Ben Pfaff Sept. 17, 2015, 9:08 p.m. UTC | #1 
On Thu, Sep 17, 2015 at 02:27:07PM -0400, Russell Bryant wrote:
> 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 <rbryant@redhat.com>

Applied, thanks!
diff mbox

Patch

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.