Reiner Sailer
2006-Feb-24 05:38 UTC
[Xense-devel] Preview/RFC: Xen/ACM security support for migration
This is a preview of what we currently prepare for the Mandatory Access
Control in Xen to better support save/restore and migration based on those
primitives. Live-migration will be dealt with in a later patch if
necessary. This is also a Request For Comments and serves as an
opportunity for early feedback.
Background:
==========Domains (and in ongoing work also resources) can be labelled in Xen
and
the Xen hypervisor controls sharing between domains (through
communication, shared resources) based on these labels and the activated
security policy. The access control granularity is coarse and suited for
strong and robust protection of distributed workloads across workload
balancing (e.g., through migration) and virtualized resources.
Problem [discussed a while ago on Xense-devel]:
==========================================Currently, the security label for a
domain/resource is represented by a
single ssidref-number in the domain configuration file, e.g., when
labeling a domain with the security label "dom_Fun" under the
CHWALL_STE
policy, the domain config file is tagged with "ssidref=196611" using
the
setlabel.sh command.
This ssid-reference is a pointer to the Xen-hypervisor internal
representation of labels and can vary for the same labelname on different
systems or policy translations (mappings). In case a domain is saved, this
local number is saved with the domain. If the domain is restored under
another policy or under the same policy on another system, then the
meaning of this ssidref might not be the intended one and the
re-instantiated domain might not be correctly controlled.
Solution:
======There are 2 different policy representations in Xen/ACM:
1. the source policy using label names and policy names, written in XML
(semantically rich)
2. the binary policy, translated from the source policy and used inside
the Xen hypervisor ACM (condensed, harder to read)
Instead of tagging the domain configuration with the ssidref, we will tag
the domain configuration with the label name and the policy name and
translate label/policy into the ssidref when instantiating a domain.
Consequently, the anticipated patch (in work) will introduce a new
configuration parameter acm_label. One example:
acm_label = [
''labelname=dom_Fun,policyname=CHINESE_WALL_AND_SIMPLE_TYPE_ENFORCEMENT''
]
This acm_label is translated into the local system''s ssidref at the
time
when a domain is created (new) or restored (from a saved file). Since
labelname and policyname are understood the same way among multiple
systems, saving a domain and restoring the domain on the same or another
system (migration) will result in the correct local ssidref translation.
Domains will be controlled correctly according to the semantic of their
label. The policyname information as part of the acm_label is used to
ensure that a domain is always instantiated under the same policy so that
the interpretation of the label will result in the same access decisions
across save/restore/migrate.
Related Changes Preview: (mainly in the tools directory)
===============================================a) new config parameter acm_label
(the old ssidref config parameter will
be supported as well because it can make sense in a cluster environment
where mapping files and xml-policies are not locally stored on each system
and the exactly same policy is enforced across multiple machines; however
using ssidref is strongly discouraged in all other cases)
b) integration of all security-related domain information into a xenstore
sub-directory
"security" subdirectory in the xenstore, here an abbrev. example:
/vm/ba0ffa8d-1381-5d34-e6ea-bb921045fabf/security/
/vm/ba0ffa8d-1381-5d34-e6ea-bb921045fabf/security/acm_label
/vm/ba0ffa8d-1381-5d34-e6ea-bb921045fabf/security/acm_label/labelname="dom_Fun"
/vm/ba0ffa8d-1381-5d34-e6ea-bb921045fabf/security/acm_label/policyname="CHINESE..."
/vm/ba0ffa8d-1381-5d34-e6ea-bb921045fabf/security/ssidref="196611"
(likely, the policy names will be changed to shorter names soon :-)
c) integration into xm list and xm list--long. Here real examples:
(we derive label names for domains that are configured with ssidref; e.g.,
dom0 has no config and currently is assigned a pre-defined ssidref during
system start)
#xm list
Name ID Mem(MiB) VCPUs State Time(s) ACM-Label
Domain-0 0 1956 1 r----- 1300.4 dom_SystemManagement
fun 15 164 1 -b---- 7.1 dom_Fun
#xm list --long
(domain
(domid 0)
(uuid 00000000-0000-0000-0000-000000000000)
(vcpus 4)
(vcpu_avail 15)
(cpu_weight 1.0)
(memory 1956)
(maxmem 1956)
(name Domain-0)
(on_poweroff destroy)
(on_reboot restart)
(on_crash restart)
(security ((ssidref 65537))) <--- dom0 has no config file
(state r-----)
(shutdown_reason poweroff)
(cpu_time 1300.83283342)
(online_vcpus 1)
)
(domain
(domid 15)
(uuid ba0ffa8d-1381-5d34-e6ea-bb921045fabf)
(vcpus 1)
(vcpu_avail 1)
(cpu_weight 1.0)
(memory 164)
(maxmem 164)
(name fun)
(on_poweroff destroy)
(on_reboot restart)
(on_crash restart)
(image
(linux
(kernel /boot/vmlinuz-2.6.16-rc2-xenU)
(ramdisk /boot/U1_ramdisk.img)
(ip :1.2.3.4::::eth0:dhcp)
)
)
(security
((acm_label <---specified in config
(labelname dom_Fun)
(policyname CHINESE_WALL_AND_SIMPLE_TYPE_ENFORCEMENT)
)
(ssidref 196611) <---calculated
)
)
(device (vif (backend 0) (script vif-bridge) (mac 00:16:3e:7e:90:d7)))
(state -b----)
(shutdown_reason poweroff)
(cpu_time 7.092087241)
(online_vcpus 1)
(up_time 74.7687170506)
(start_time 1140748464.58)
(store_mfn 807763)
(console_mfn 807762)
)
Feedback welcome.
Thanks
Reiner
_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel