Comment 6 for bug 1456228

The boot order change is the simplest way to make the Attestation server
think this specific compute node has been "compromised", and it worked.

Please be noted this vm was previously launched from the same host, which
were in trusted status. But, we expect the same VM not be able to powered
back on when the attestation has marked the host as untrusted per the
design.

On Mon, Jun 8, 2015 at 3:07 PM, Malini Bhandaru <<email address hidden>
> wrote:

> 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 subscribed to the bug
> report.
> 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@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
>