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

[Xen-API] RFC: Support for secruity in Xen-API

To: xen-api@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-API] RFC: Support for secruity in Xen-API
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Mon, 20 Nov 2006 15:50:35 -0500
Cc: Steven Hand <Steven.Hand@xxxxxxxxxxxx>, Reiner Sailer <sailer@xxxxxxxxxx>
Delivery-date: Mon, 20 Nov 2006 12:50:57 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

Hello!

  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:

http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user/user.html#SECTION03730000000000000000
http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user/user.html#SECTION03734000000000000000


An xml schema for sHype policies can be found here:

http://xenbits.xensource.com/xen-unstable.hg?f=690a4b39819b;file=tools/security/policies/security_policy.xsd


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)
optional:
        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)
optional:
        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)
optional:
        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") =
                               "sHype:vm:test-wld:dom_System"

    methods:

        VM.setlabel(label record)
        label record= VM.getlabel()
        VM.rmlabel()
        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"      ) =
                               "sHype:res:test-wld:blue"

    methods:

        VBD.setlabel(label record)
        label record = VBD.getlabel()
        VBD.rmlabel()
        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)

    methods:

        VIF.setlabel(label record)
        label record = VIF.getlabel()
        VM.rmlabel()
        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
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-API] RFC: Support for secruity in Xen-API, Stefan Berger <=