[Xense-devel] Preview/RFC: Xen/ACM security support for migration

[Reiner Sailer <sailer@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel