Open Stack

It is unclear if this is OSSN worthy, as it may be expected (if sub-
optimal) behaviour. To recap, the steps listed to reproduce described
above:

* 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.

I am under the impression that the trust status is only checked at boot
time, so unless the node is rebooted after changing the boot order, the
attestation information available to trusted_filter will still say that
the node is trusted, and therefore will allow the instance to start.
However, if the node is rebooted, the attestation information should
prevent that node from restarting - this should be verified, although
Slynvain states on 2015-06-24 that instances are spawned correctly,
which implies that nova is functioning as it should.

Clearly this is sub-optimal to boot instances on a compromised nova
node, but I believe this is expected behaviour for a trusted boot system
(it is one of the known defects with trusted computing) . If I am
correct, we should document this via the compute section of the security
guide, rather than issuing an OSSN. Any update to the security guide
should include the expected situations that the attestation service
should prevent instance boot, and the cases where instances can still
boot.

-- 
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:
  Incomplete

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