* Re: SSIDs and domain migration
2006-01-20 1:18 SSIDs and domain migration Anthony Liguori
@ 2006-01-20 2:58 ` Reiner Sailer
0 siblings, 0 replies; 2+ messages in thread
From: Reiner Sailer @ 2006-01-20 2:58 UTC (permalink / raw)
To: aliguori; +Cc: xen-devel, Stefan Berger, xense-devel
[-- 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
^ permalink raw reply [flat|nested] 2+ messages in thread