RFC: Support for secruity in Xen-API

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

RFC: Support for secruity in Xen-API

Stefan Berger


  Below is our proposal for an extension of the Xen-API to include methods for supporting management of security policies and the labeling of virtual machines and resources. We have tried to take into consideration that there might be multiple different policy frameworks available for Xen which could possibly be running at the same time. Therefore we have made some of the function calls and data structures as generic as possible such that different policy types can be accomodated. Currently, however, there is only one security architecture implemented in Xen and that is the sHype architecture along with its access control module (ACM) in the hypervisor. sHype requires that virtual machines be labeled with a security labels in the VM configuration file as well as the labeling of resurces (disk, network). The enforcment in the sHype architecture happens for example through matching of a VM's label against those of a resource for allowing or denying access to the resource.

  Some of the functions below deal with updating a security policy's entries, which may be necessary to do in case of VM migration. These functions provide means for manipulating a policy kept on the managed system and remove portions of the entries or add some new ones. In case of sHype the policies are written in xml format.
Examples for currently available policies can be found in the user guide in section 10.3 and 10.3.4:


An xml schema for sHype policies can be found here:


New datatypes and constants can be found below the API descriptions.

Extensions to class ' host':

xsmtype = host.getXSMType(session_id s)
        Returns the supported policy type of the system; may be POLICY_NONE if support for
        hypervisor-enforced policies is not supported

policystate record = host.setXSMPolicy(session_id s,
                                       xsmtype type,
                                       <xml representation of policy>,
                                       instantiationflags flags,
                                       bool overwrite)
        Set the given policy according to the instantiation flags. If overwrite is 'true',
        an existing policy may be overwritten. The operation must succeed in whole and indicate
        failure otherwise.

policystate record = host.getXSMPolicy(session_id s, xsmtype type)
        Get a reference to the currently active policy of the given type or 'None'; this includes
      the current instantiation flags of that policy.

errorcode = host.rmXSMBootPolicy(session_id s, xsmtype type)
        Remove the given policy type from being automatically loaded into the hypervisor when
      the system is booted

New class XSMPolicy:

Methods for manipulating XSMPolicy objects:

Functions related to the header of the policy

errorcode =                XSMPolicy.setsHypeHeader(session_id s, shypepolicyheader record args, xsmpolicy ref)
shypepolicyheader record = XSMPolicy.getsHypeHeader(session_id s,                                xsmpolicy ref)

Functions related to types such as 'simple type enforcement' or 'chinese wall':

errorcode = XSMPolicy.addType(session_id s, component c, string type, xsmpolicy ref)
errorcode = XSMPolicy.rmType (session_id s, component c, string type, xsmpolicy ref)
        string[] = XSMPolicy.getTypes(session_id s, component c, xsmpolicy ref)

Functions related to conflict sets of the 'chinese wall':

errorcode = XSMPolicy.addConflictSet(session_id s, conflictset record args, xsmpolicy ref)
errorcode = XSMPolicy.rmConflictSet (session_id s, conflictset record args, xsmpolicy ref)
        conflictset record[] = XSMPolicy.getConflictSets(session_id s, xsmpolicy ref)

Functions related to labels for virtual machines and resources:

errorcode = XSMPolicy.addLabel(session_id s, label record args, xsmpolicy ref)
errorcode = XSMPolicy.rmLabel (session_id s, string name      , xsmpolicy ref)
        label record[] = XSMPolicy.getLabels(session_id s, xsmpolicy ref, labeltype types)

<xml policy>    = XSMPolicy.getXML   (session_id s, xsmpolicy ref)
<policy map>    = XSMPolicy.getMap   (session_id s, xsmpolicy ref)
<binary policy> = XSMPOlicy.getBinary(session_id s, xsmpolicy ref)

Extensions to class VM:

        RO_ins   security/xsmtype     xsmtype           type of policy the label refers to
        RO_ins   security/label       string            the actual label of the VM

        Displayformat for vm : (xsmtype/string) =
                               (POLICY_SHYPE, "test-wld:dom_System") =


        VM.setlabel(label record)
        label record= VM.getlabel()
        label record = VM.relabel(label record)

Extensions to class VBD:

        RO_ins   security/xsmtype      xsmtype           type of policy the label refers to
        RO_ins   security/label        string            the actual label of the resource

        Displayformat for VBD: (xsmtype/string) =
                               (POLICY_SHYPE, "test-wld:blue"      ) =


        VBD.setlabel(label record)
        label record = VBD.getlabel()
        label record = VBD.relabel(label record)

Extensions to class VIF:

        RO_ins  security/xsmtype      xsmtype           type of policy the label refers to
        RO_ins  security/label        string            the actual label of the resource

        Displayformat for VIF: (xsmtype/string) =
                                 (POLICY_SHYPE, "test-wld:green"     ) =
                                 "sHype:res:test-wld:green"    (similar as VBD)


        VIF.setlabel(label record)
        label record = VIF.getlabel()
        label record = VIF.relabel(label record)

Basic datatypes and constants:

xsmtype {
        POLICY_NONE = 0
        POLICY_SHype = (1 << 0)  // use 'flag' to allow multiple types of policies

instantiationflags {
        INST_NONE        = ""
        INST_BOOT        = (1 << 0)  // set this policy as the one to boot the system with
        INST_LOAD         = (1 << 1)  // immediately load this policy into the hypervisor

component {
        COMPONENT_SHYPE_STE         = 1
        COMPONENT_SHYPE_CHWALL         = 2

labeltype = {
        SHYPE_LABEL_VM                = 1
        SHYPE_LABEL_RES                = 2

        labeltype can be used as a 'logical or' concatenation of flags to for example
        request different types of labels be returned from XSMPolicy.getLabels(...)

Datatypes for operations on a policy:

shypepolicyheader record {    // shype-specific datastructure
        string policyname              // cannot be changed while a policy is being used
        string policyurl
        string date
        string version          // new version of the policy, i.e., after an update

conflictset record {
        string name                    // name of the conflict set
        string chwalltypes[]    // array of chinese wall types in the conflict set

policylabel record {
        labeltype type          // the type of label: shype-vm, shype-resource, etc.
        string name                    // the name of the label; in case of a VM-label this would be the label
                                // given to a VM using VM.setlabel()
        string stetypes[]       // the simple type enforcement types associated with this VM or resource
        string chwalltypes[]    // the chinese wall types associated with this VM or resource

policystate record {
        xsmpolicy ref                 // a reference to the xsm policy object
        instantiationflags flags      // current instantiation flags of the policy
        string xmlpolicy              // xml-representation of the policy

Datatypes for labeling of resources or VMs:

label record {
        xsmtype type            // type of policy the label referes to
        String  label           // the actual label of the resource

   Stefan and Reiner

Xense-devel mailing list
[hidden email]