Open Stack

Does the design specify that the VM should not be powered back on when
the system reboots? I ask because I think that is a different problem.
With the scheduling problem there is an outside entity from Nova that
can ask for attestation and enforce not giving the VM to an untrusted
host.

In this use case Nova would be responsible (I'm asking here and not
stating, so please clarify if wrong) for asking for attestation and
enforcing not launching a VM. If it is then this is risky because Nova
would report measurements and enforce the decision as to whether or not
to launch the VM. If Nova has been compromised then it could ignore
whatever response is from attestation service or ignore it completely.

I'm not sure what is in scope for requirements and design of trusted
pools.

-- 
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):
  New
Status in OpenStack Security Advisories:
  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