SSIDs and domain migration

SSIDs and domain migration

[Anthony Liguori]

Hi Reiner,

There was quite a bit of talk at the Summit about the difficulties of 
migration in secure Xen.  I know one area of difficulty is managing the 
SSID references since they're only meaningful on the local machine and 
depend on the installed policies.

Could you comment on how this could be handled today in Xen?  Should 
migration ignore the SSID refs for now?  Is there a complete long term 
solution?

Thanks,

Anthony Liguori

Re: SSIDs and domain migration

[Reiner Sailer]

[-- Attachment #1.1: Type: text/plain, Size: 5516 bytes --]

aliguori@us.ltcfwd.linux.ibm.com wrote on 01/19/2006 08:18:44 PM:

> Hi Reiner,

Hi Anthony,


> There was quite a bit of talk at the Summit about the difficulties of 
> migration in secure Xen.  I know one area of difficulty is managing the 
> SSID references since they're only meaningful on the local machine and 
> depend on the installed policies.


This is an important topic to discuss.

You are right, SSID references are local. When a domain is saved and 
restored on the same system under the same policy, then this works 
naturally. If a domain is migrated (or restored under another binary 
policy), then this local ssidref of the originating system must be 
translated to the ssid reference on the destination system so that it 
matches the protection property of the originating system. [For system 
clusters, the same binary policy can be distributed to all systems and 
ssidref translation might not be necessary.]


> Could you comment on how this could be handled today in Xen?  Should 
> migration ignore the SSID refs for now? 

SSIDrefs can be ignored if security is not configured. If ACM security is 
configured and active, then ssidrefs cannot be ignored. In this case, the 
problem must be either fixed or labeled VMs should not be migrated (I opt 
for fixing it).

The way source xml security policies and labels are translated into the 
local binary ssid references enables us to translate back and forth 
between ssidref and label names on a single system. We use this in scripts 
to label and display virtual machine security configurations.

Assuming that migration takes place between mutually trusted machines that 
understand the same security label names, one solution can be outlined as 
follows and could be integrated into the migration tools:

a) before migrating a labeled domain from system A to system B, the 
migration management applications on both systems must synchronize and 
ensure that both systems run the same policy types (e.g., Chinese Wall & 
Simple Type Enforcement). If they don't run the same type of policy (e.g., 
system A runs STE, system B runs NULL), then migration cannot take place 
within the access control environment. Any domain 0 can retrieve the 
current policy configuration from the hypervisor using the "xensec_tool 
get_policy" command and reading the primary and secondary policy names 
from the returned buffer.

 --> I assume that there is already some synchronization going on between 
A and B to sync other migration information and that the policy 
information could be included here

b) before migrating a domain, translate the local ssidref of the domain 
into the more generic label name that is understood by both systems (e.g., 
in the current example policy an ssidref of 0x00020002 could translate 
into the label name dom_HomeBanking)

 --> the following command sequence can be used to achieve this:
i)  read the 'ssidref' from the vm description (here: 0x00020002)
ii) /etc/xen/acm-security/scripts/getlabel.sh -sid 'ssidref'
(will yield the policy and the label name which can be awk'ed from there)
iii) replace the local ssidref with the ascii label in the vm description
The length of the vm description header is likely to changes here, since 
the label name might have more or less characters than the ssidref number.

c) before instantiating a migrated domain on the destination system, 
translate the generic label name back into the matching local ssidref

--> the following command sequence can be used to re-label the 
configuration file:
i) read the label name from the vm description (inserted before migration, 
see above)
ii) translate the label into the ssidref on the destination system
(the security tools setlabel.sh script should be extended to enable the 
translation of a label into a ssidref without writing it into a vm config 
file) 
iii) write this new ssidref into the vm description before instantiating 
the domain on the destination system (could be combined with ii) in a new 
option of setlabel.sh)
The length of the vm description header will likely change, since label 
and ssidref might have different character lengths.

>Is there a complete long term 
> solution?

It might be helpful to add a "domain of interpretation" into the policy 
files' metadata. This field links an xml policy to the interpretation of 
the defined policy labels. By verifying that both A and B link to the same 
interpretation (interpretations should be from a universal name space), 
they can ensure that they not only know the same label names but that they 
also have a common and compatible interpretation of what the label is 
supposed to mean.

The outlined solution also assumes that both systems trust each other. 
Later on, we can extend such a migration to achieve stronger guarantees by 
using remote attestation to verify or establish the security properties of 
the security enforcement and the enforced policy on the destination 
system. Additionally, the mapping of label names between policies of 
different domains of interpretation can be added to make the solution more 
generic.

Finally, there seems to be interesting work left in figuring out if and 
how different security policies have compatible enforcement properties. 
While the fully generic approach might be very hard to solve, restricting 
the policies might lead to solutions that cover sufficient usage scenarios 
in an automatic fashion.

Does this sound like a reasonable approach ?

> Thanks,
> 
> Anthony Liguori

Thanks
Reiner

[-- Attachment #1.2: Type: text/html, Size: 6698 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel