[Xen-devel] Re: SSIDs and domain migration

[Reiner Sailer <sailer@xxxxxxxxxx>]

aliguori@xxxxxxxxxxxxxxxxxxxxxxx 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel