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

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

WARNING - OLD ARCHIVES

xen-api

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