yahoo-eng-team team mailing list archive

[Sylvain Bauza <sbauza@xxxxxxx>]

The TrustedFilter filter actually doesn't check by itself but rather
calls the Attestation API to know if the destination host is correct or
not. That way, it's just when the instance is scheduled that it goes to
the scheduler, then finds an acceptable destination (so calls the
Attestation API for each host to see if it's compromised or not) and
then calls the corresponding compute node to spawn that VM.

Once the VM is spawned, the scheduler is no longer involved unless a migration, a resize or an evacuation is asked for that VM.
That means that having a valid host, running a VM, stopping it, compromising the host, then restarting the VM is something that Nova doesn't check, because it's not its responsibility.

To be clear, Nova doesn't want to support that feature.

** Changed in: nova
       Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
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 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@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