WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: SSIDs and domain migration

To: aliguori@xxxxxxxxxx
Subject: [Xen-devel] Re: SSIDs and domain migration
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Thu, 19 Jan 2006 21:58:56 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefan Berger <stefanb@xxxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 20 Jan 2006 03:06:52 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43D03A74.8030907@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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
<Prev in Thread] Current Thread [Next in Thread>