Open Stack

Reviewed:  https://review.openstack.org/194592
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=e134536d0a7a555088f1af5d75d573ed50352f1a
Submitter: Jenkins
Branch:    master

commit e134536d0a7a555088f1af5d75d573ed50352f1a
Author: Sylvain Bauza <sbauza at redhat.com>
Date:   Fri Sep 18 12:38:12 2015 +0200

    Set TrustedFilter as experimental
    
    The TrustedFilter is the only in-tree scheduler filter that calls an external
    3rd-party service (OpenAttestation) for decision-making. Thus, the OAT service
    is not listed as an official Nova dependency and consequently not even gated,
    even by a 3rd-party CI.
    
    Besides, some discussions have been captured in a ML thread that show that
    running this filter is not the best way for enforcing trusted compute nodes [1]
    but I leave that out of the review (just a FYI) because the main reason for
    making experimental the filter is to send a signal to operators that they will
    either have to find another solution or accept the current gaps.
    
    [1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/067766.html
    
    Related-Bug: #1456228
    
    Change-Id: I6ab013faf22a0e88424207830ec399724f827622

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1456228

Title:
  Trusted vm can be powered on untrusted host

Status in OpenStack Compute (nova):
  Invalid
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Confirmed

Bug description:
  This is related to the trusted compute.

  I recently setup trusted compute pool in my company and have observed
  that although new trusted vm is not able to be launched from an
  untrusted host, but if an trusted vm that have launched earlier on a
  trusted host which is compromised later on, that VM can still be
  powered on.

  1. Exact version of Nova/Openstack:
  [root at grunt2 ~]# rpm -qa | grep nova
  python-nova-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-network-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-compute-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-conductor-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-cells-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-api-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-console-2014.1.2-100+45c2cbc.fc20.noarch
  python-novaclient-2.17.0-2.fc21.noarch
  openstack-nova-cert-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-scheduler-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-objectstore-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-common-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-novncproxy-2014.1.2-100+45c2cbc.fc20.noarch
  openstack-nova-doc-2014.1.2-100+45c2cbc.fc20.noarch

  2. Relevant log files:
  this is not a error, don't think logs will help..

  3.  Reproduce steps:

  * create trusted compute pool  with only one compute node
  * create an trusted VM on that compute node
  * compromise the trusted compute node by changing the boot order
  * power on the trusted Vm created earlier.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1456228/+subscriptions