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
 
   
 

xense-devel

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

To: xense-devel@xxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xense-devel] Preview/RFC: Xen/ACM security support for migration
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Fri, 24 Feb 2006 00:38:05 -0500
Cc: Ramon Caceres <caceres@xxxxxxxxxx>, Stefan Berger <stefanb@xxxxxxxxxx>
Delivery-date: Fri, 24 Feb 2006 05:38:47 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx

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
<Prev in Thread] Current Thread [Next in Thread>
  • [Xense-devel] Preview/RFC: Xen/ACM security support for migration, Reiner Sailer <=