Open Stack

Something to consider: how legitimate is this test scenario in a production cloud.
1) A host upgrade, boot order change -- this would be in the realm of admin privileges.
2) Should this be part of scheduled maintenance, more likely than not, the admin would have evacuated all virtual machines from said host prior to upgrade, in which case Nova scheduler would be involved and the VM would be migrated to another trusted host.

And something to consider with respect to security hardening:
1) On host re-boot, as part of initialization step, it would be good to determine if it still is trusted if earlier on it was a trusted machine.

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