[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] PATCH [1/4] sHype/ACM User Guide Chapter

This patch updates the user guide for Xen with a chapter describing the sHype/ACM security module for Xen. Section 10.2 offers a quick guide showing how to setup and test the workload protection with sHype/ACM in Xen.

Patch [2of4] will include figure 1 for this new chapter
Patch [3of4] will include figure 2 for this new chapter
patch [4of4] will include a wxPython GUI tool for creating quickly sHype/ACM security policies; it is used and described in the quick guide for sHype/ACM in Xen (Section 10.2)


Signed-off by: Reiner Sailer <sailer@xxxxxxxxxx>

 docs/src/user.tex |  982 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 982 insertions(+)

Index: xen-unstable.hg-shype/docs/src/user.tex
--- xen-unstable.hg-shype.orig/docs/src/user.tex
+++ xen-unstable.hg-shype/docs/src/user.tex
@@ -2060,6 +2060,988 @@ iptables:
 iptables -A INPUT -p tcp -{}-destination-port 8002 -j REJECT
+%% Chapter Xen Mandatory Access Control Framework
+\chapter{sHype/Xen Access Control}
+The Xen mandatory access control framework is an implementation of the
+sHype Hypervisor Security Architecture
+(www.research.ibm.com/ssd\_shype). It permits or denies communication
+and resource access of domains based on a security policy. The
+mandatory access controls are enforced in addition to the Xen core
+controls, such as memory protection.  They are designed to remain
+transparent during normal operation of domains (policy-conform
+behavior) but to intervene when domains move outside their intended
+sharing behavior.  This chapter will describe how the sHype access
+controls in Xen can be configured to prevent viruses from spilling
+over from one into another workload type and secrets from leaking from
+one workload type to another. sHype/Xen depends on the correct
+behavior of Domain0 (cf previous chapter).
+Benefits of configuring sHype/ACM in Xen include:
+\item robust workload and resource protection effective against rogue
+  user domains
+\item simple, platform- and operating system-independent security
+  policies (ideal for heterogeneous distributed environments)
+\item safety net with minimal performance overhead in case operating
+  system security is missing, does not scale, or fails
+These benefits are very valuable because today's operating systems
+become increasingly complex and often have no or insufficient
+mandatory access controls.  (Discretionary access controls, supported
+by of most operating systems, are not effective against viruses or
+misbehaving programs.)  Where mandatory access control exists (e.g.,
+SELinux), they usually deploy complex and difficult to understand
+security policies.  Additionally, multi-tier applications in business
+environments usually require different types of operating systems
+(e.g., AIX, Windows, Linux) which cannot be configured with compatible
+security policies. Related distributed transactions and workloads
+cannot be easily protected on the OS level. The Xen access control
+framework steps in to offer a coarse-grained but very robust security
+layer and safety net in case operating system security fails or is
+To control sharing between domains, Xen mediates all inter-domain
+communication (shared memory, events) as well as the access of domains
+to resources such as disks. Thus, Xen can confine distributed
+workloads (domain payloads) by permitting sharing among domains
+running the same type of workload and denying sharing between pairs of
+domains that run different workload types. We assume that--from a Xen
+perspective--only one workload type is running per user domain. To
+enable Xen to associate domains and resources with workload types,
+security labels including the workload types are attached to domains
+and resources. These labels and the hypervisor sHype controls cannot
+be manipulated or bypassed and are effective even against rogue
+This section gives an overview of how workloads can be protected using
+the sHype mandatory access control framework in Xen.
+Figure~\ref{fig:acmoverview} shows the necessary steps in activating
+the Xen workload protection. These steps are described in detail in
+\caption{Overview of activating sHype workload protection in Xen.
+  Section numbers point to representative examples.}
+First, the sHype/ACM access control must be enabled in the Xen
+distribution and the distribution must be built and installed (cf
+Subsection~\ref{subsection:acmexampleconfigure}). Before we can
+enforce security, a Xen security policy must be created (cf
+Subsection~\ref{subsection:acmexamplecreate}) and deployed (cf
+Subsection~\ref{subsection:acmexampleinstall}).  This policy defines
+the workload types differentiated during access control. It also
+defines the rules that compare workload types of domains and resources
+to provide access decisions. Workload types are represented by
+security labels that can be attached to domains and resources (cf
+and~\ref{subsection:acmexamplelabelresources}).  The functioning of
+the active sHype/Xen workload protection is demonstrated using simple
+resource assignment, and domain creation tests in
+Section~\ref{section:acmpolicy} describes the syntax and semantics of
+the sHype/Xen security policy in detail and introduces briefly the
+tools that are available to help create valid security policies.
+The next section describes all the necessary steps to create, deploy,
+and test a simple workload protection policy. It is meant to enable
+anybody to quickly try out the sHype/Xen workload protection. Those
+readers who are interested in learning more about how the sHype access
+control in Xen works and how it is configured using the XML security
+policy should read Section~\ref{section:acmpolicy} as well.
+Section~\ref{section:acmlimitations} concludes this chapter with
+current limitations of the sHype implementation for Xen.
+\section{Xen Workload Protection Step-by-Step}
+What you are about to do consists of the following sequence:
+\item configure and install sHype/Xen
+\item create a simple workload protection security policy
+\item deploy the sHype/Xen security policy
+\item associate domains and resources with workload labels,
+\item test the workload protection
+The essential commands to create and deploy a sHype/Xen security
+policy are numbered throughout the following sections. If you want a
+quick-guide or return at a later time to go quickly through this
+demonstration, simply look for the numbered commands and apply them in
+\subsection{Configuring/Building sHype Support into Xen}
+First, we need to configure the access control module in Xen and
+install the ACM-enabled Xen hypervisor. This step installs security
+tools and compiles sHype/ACM controls into the Xen hypervisor.
+To enable sHype/ACM in Xen, please edit the Config.mk file in the top
+Xen directory.
+  (1) In Config.mk
+        Change: ACM_SECURITY ?= n
+            To: ACM_SECURITY ?= y
+Then install the security-enabled Xen environment as follows:
+  (2) # make world
+      # make install
+\subsection{Creating A WLP Policy in 3 Simple Steps with ezPolicy}
+We will use the ezPolicy tool to quickly create a policy that protects
+workloads.  You will need both the Python and wxPython packages to run
+this tool.  To run the tool in Domain0, you can download the wxPython
+package from www.wxpython.org or use the command
+\verb|yum install wxPython| in Redhat/Fedora. To run the tool on MS
+Windows, you also need to download the Python package from
+www.python.org. After these packages are installed, start the ezPolicy
+tool with the following command:
+  (3) # xensec_ezpolicy
+Figure~\ref{fig:acmezpolicy} shows a screen-shot of the tool. The
+following steps show you how to create the policy shown in
+Figure~\ref{fig:acmezpolicy}.  You can use \verb|<CTRL>-h| to pop up a
+help window at any time. The indicators (a), (b), and (c) in
+Figure~\ref{fig:acmezpolicy} show the buttons that are used during the
+3 steps of creating a policy:
+\item defining workloads
+\item defining run-time conflicts
+\item translating the workload definition into a sHype/Xen access
+  control policy
+\paragraph{Defining workloads.} Workloads are defined for each
+organization and department that you enter in the left panel. Please
+use the ``New Org'' button (a) to create the organizations ``Avis'',
+``Hertz'', ``CocaCola'', and ``PepsiCo''.
+You can refine an organization to differentiate between multiple
+department workloads by right-clicking the organization and selecting
+\verb|Add Department| (or selecting an organization and pressing
+\verb|<CRTL>-a|). Create department workloads ``Intranet'',
+``Extranet'', ``HumanResources'', and ``Payroll'' for the ``CocaCola''
+organization and department workloads ``Intranet'' and ``Extranet''
+for the ``PepsiCo'' organization. The resulting layout of the tool
+should be similar to the left panel shown in
+\paragraph{Defining run-time conflicts.} Workloads that shall be
+prohibited from running concurrently on the same hypervisor platform
+are grouped into ``Run-time Exclusion rules'' on the right panel of
+the window.
+To prevent PepsiCo and CocaCola workloads (including their
+departmental workloads) from running simultaneously on the same
+hypervisor system, select the organization ``PepsiCo'' and, while
+pressing the \verb|<CTRL>|-key, select the organization ``CocaCola''.
+Now press the button (b) named ``Create run-time exclusion rule from
+selection''. A popup window will ask for the name for this run-time
+exclusion rule (enter a name or just hit \verb|<ENTER>|). A rule will
+appear on the right panel. The name is used as reference only and does
+not affect the hypervisor policy.
+Repeat the process to create a run-time exclusion rule just for the
+department workloads CocaCola.Extranet and CocaCola.Payroll.
+\caption{Final layout including workload definition and Run-time Exclusion 
+The resulting layout of your window should be similar to
+Figure~\ref{fig:acmezpolicy}. Save this workload definition by
+selecting ``Save Workload Definition as ...'' in the ``File'' menu
+(c).  This workload definition can be later refined if required.
+\paragraph{Translating the workload definition into a sHype/Xen access
+  control policy.} To translate the workload definition into a access
+control policy understood by Xen, please select the ``Save as Xen ACM
+Security Policy'' in the ``File'' menu (c). Enter the following policy
+name in the popup window: \verb|example.chwall_ste.test-wld|. If you
+are running ezPolicy in Domain0, the resulting policy file
+test-wld\_security-policy.xml will automatically be placed into the
+right directory (/etc/xen/acm-security/ policies/example/chwall\_ste).
+If you run the tool on another system, then you need to copy the
+resulting policy file into Domain0 before continuing.  See
+Section~\ref{subsection:acmnaming} for naming conventions of security
+\subsection{Deploying a WLP Policy}
+To deploy the workload protection policy we created in
+Section~\ref{subsection:acmexamplecreate}, we create a policy
+representation (test-wld.bin) that can be loaded into the Xen
+hypervisor and we configure Xen to actually load this policy at
+startup time.
+The following command translates the source policy representation
+into a format that can be loaded into Xen with sHype/ACM support.
+Refer to the \verb|xm| man page for further details:
+  (4) # xm makepolicy example.chwall_ste.test-wld
+The easiest way to install a security policy for Xen is to include the
+policy in the boot sequence. The following command does just this:
+  (5) # xm cfgbootpolicy example.chwall_ste.test-wld
+\textit{Alternatively, if this command fails} (e.g., because it cannot
+identify the Xen boot entry), you can manually install the policy in 2
+steps.  First, manually copy the policy binary file into the boot
+         # cp /etc/xen/acm-security/policies/example/chwall_ste/test-wld.bin \
+         /boot/example.chwall_ste.test-wld.bin
+Second, manually add a module line to your Xen boot entry so that grub
+loads this policy file during startup:
+         title Xen (
+                root (hd0,0)
+                kernel /xen.gz dom0_mem=2000000 console=vga
+                module /vmlinuz- ro root=/dev/hda3
+                module /initrd-
+                module /example.chwall_ste.test-wld.bin
+Now reboot into this Xen boot entry to activate the policy and the
+security-enabled Xen hypervisor.
+  (6) # reboot
+After reboot, check if security is enabled:
+         # xm list --label
+         Name        ID Mem(MiB) VCPUs State  Time(s)  Label
+         Domain-0     0     1949     4 r-----   163.9  SystemManagement
+If the security label at the end of the line says ``INACTIV'' then the
+security is not enabled. Verify the previous steps. Note: Domain0 is
+assigned a default label (see \verb|bootstrap| policy attribute
+explained in Section~\ref{section:acmpolicy}). All other domains must
+be labeled in order to start on this sHype/ACM-enabled Xen hypervisor
+(see following sections for labeling domains and resources).
+\subsection{Labeling Domains}
+You should have a Xen domain configuration file that looks like the
+following (Note: www.jailtime.org or www.xen-get.org might be good
+places to look for example domU images). The following configuration
+file defines \verb|domain1|:
+         # cat domain1.xm
+         kernel = "/boot/vmlinuz-"
+         memory = 128
+         name = "domain1"
+         vif = [ '' ]
+         dhcp = "dhcp"
+         disk = ['file:/home/xen/dom_fc5/fedora.fc5.img,sda1,w', \
+                 'file:/home/xen/dom_fc5/fedora.swap,sda2,w']
+         root = "/dev/sda1 ro"
+If you try to start domain1, you will get the following error:
+         # xm create domain1.xm
+         Using config file "domain1.xm".
+         domain1: DENIED
+         --> Domain not labeled
+         Checking resources: (skipped)
+         Security configuration prevents domain from starting
+Every domain must be associated with a security label before it can
+start on sHype/Xen. Otherwise, sHype/Xen would not be able to enforce
+the policy consistently. The following command prints all domain
+labels available in the active policy:
+         # xm labels type=dom
+         Avis
+         CocaCola
+         CocaCola.Extranet
+         CocaCola.HumanResources
+         CocaCola.Intranet
+         CocaCola.Payroll
+         Hertz
+         PepsiCo
+         PepsiCo.Extranet
+         PepsiCo.Intranet
+         SystemManagement
+Now label domain1 with the CocaCola label and another domain2 with the
+PepsiCo.Extranet label. Please refer to the xm man page for further
+  (7) # xm addlabel CocaCola dom domain1.xm
+      # xm addlabel PepsiCo.Extranet dom domain2.xm
+Let us try to start the domain again:
+         # xm create domain1.xm
+         Using config file "domain1.xm".
+            file:/home/xen/dom_fc5/fedora.fc5.img: DENIED
+            --> res:__NULL_LABEL__ (NULL)
+            --> dom:CocaCola (example.chwall_ste.test-wld)
+            file:/home/xen/dom_fc5/fedora.swap: DENIED
+            --> res:__NULL_LABEL__ (NULL)
+            --> dom:CocaCola (example.chwall_ste.test-wld)
+         Security configuration prevents domain from starting
+This error indicates that domain1, if started, would not be able to
+access its image and swap files because they are not labeled.  This
+makes sense because to confine workloads, access of domains to
+resources must be controlled.  Otherwise, domains that are not allowed
+to communicate or run simultaneously could share data through storage
+\subsection{Labeling Resources}
+You can use the \verb|xm labels type=res| command to list available
+resource labels. Let us assign the CocaCola resource label to the domain1
+image file representing \verb|/dev/sda1| and to its swap file:
+  (8) # xm addlabel CocaCola res \
+           file:/home/xen/dom_fc5/fedora.fc5.img
+      Resource file not found, creating new file at:
+      /etc/xen/acm-security/policies/resource_labels
+      # xm addlabel CocaCola res \
+           file:/home/xen/dom_fc5/fedora.swap
+Starting \verb|domain1| now will succeed:
+         # xm create domain1.xm
+         # xm list --label
+         Name           ID Mem(MiB) VCPUs State  Time(s)  Label
+         domain1         1      128     1 r-----     2.8  CocaCola
+         Domain-0        0     1949     4 r-----   387.7  SystemManagement
+The following command lists all labeled resources on the
+system, e.g., to lookup or verify the labeling:
+         # xm resources
+         file:/home/xen/dom_fc5/fedora.swap
+             policy: example.chwall_ste.test-wld
+             label:  CocaCola
+         file:/home/xen/dom_fc5/fedora.fc5.img
+             policy: example.chwall_ste.test-wld
+             label:  CocaCola
+Currently, if a labeled resource is moved to another location, the
+label must first be manually removed, and after the move re-attached
+using the xm commands \verb|xm rmlabel| and \verb|xm addlabel|
+respectively.  Please see Section~\ref{section:acmlimitations} for
+further details.
+  (9) Label the resources of domain2 as PepsiCo.Extranet
+      Do not try to start this domain yet
+\subsection{Testing The Xen Workload Protection}
+We are about to demonstrate how the workload protection works by
+\item that domains with conflicting workloads cannot run
+  simultaneously
+\item that domains cannot access resources of other workloads
+\item that domains cannot exchange network packets if they are not
+  associated with the same workload type
+\paragraph{Test 1: Run-time exclusion rules.} We assume that domain1
+with the CocaCola label is still running. While domain1 is running,
+the run-time exclusion set of our policy says that domain2 cannot
+start because the label of domain1 includes the CHWALL type CocaCola
+and the label of domain2 includes the CHWALL type PepsiCo. The
+run-time exclusion rule of our policy enforces that PepsiCo and
+CocaCola cannot run at the same time on the same hypervisor platform.
+Once domain1 is stopped or saved, domain2 can start but domain1 can no
+longer start or be resumed. The ezPolicy tool, when creating the
+Chinese Wall types for the workload labels, ensures that department
+workloads inherit the organization type (and with it any organization
+# xm list --label
+Name           ID Mem(MiB) VCPUs State  Time(s)  Label
+domain1         2      128     1 -b----     6.9  CocaCola
+Domain-0        0     1949     4 r-----   273.1  SystemManagement
+# xm create domain2.xm
+Using config file "domain2.xm".
+Error: (1, 'Operation not permitted')
+# xm destroy domain1
+# xm create domain2.xm
+Using config file "domain2.xm".
+Started domain domain2
+# xm list --label
+Name           ID Mem(MiB) VCPUs State  Time(s)  Label
+domain2         4      164     1 r-----     4.3  PepsiCo.Extranet
+Domain-0        0     1949     4 r-----   298.4  SystemManagement
+# xm create domain1.xm
+Using config file "domain1.xm".
+Error: (1, 'Operation not permitted')
+# xm destroy domain2
+# xm list
+Name           ID Mem(MiB) VCPUs State  Time(s)
+Domain-0        0     1949     4 r-----   391.2
+You can verify that domains with Avis label can run together with
+domains labeled CocaCola, PepsiCo, or Hertz.
+\paragraph{Test2: Resource access.} In this test, we will re-label the
+swap file for domain1 with the Avis resource label. We expect that
+Domain1 will no longer start because it cannot access this resource.
+This test checks the sharing abilities of domains, which are defined
+by the Simple Type Enforcement Policy component.
+# xm rmlabel res file:/home/xen/dom_fc5/fedora.swap
+# xm addlabel Avis res file:/home/xen/dom_fc5/fedora.swap
+# xm resources
+    policy: example.chwall_ste.test-wld
+    label:  Avis
+    policy: example.chwall_ste.test-wld
+    label:  CocaCola
+# xm create domain1.xm
+Using config file "domain1.xm".
+   file:/home/xen/dom_fc4/fedora.swap: DENIED
+   --> res:Avis (example.chwall_ste.test-wld)
+   --> dom:CocaCola (example.chwall_ste.test-wld)
+Security configuration prevents domain from starting
+\paragraph{Test 3: Communication.} In this test we would verify that
+two domains with labels Hertz and Avis cannot exchange network packets
+by using the 'ping' connectivity test. It is also related to the STE
+policy.{\bf Note:} sHype/Xen does control direct communication between
+domains. However, domains associated with different workloads can
+currently still communicate through the Domain0 virtual network. We
+are working on the sHype/ACM controls for local and remote network
+traffic through Domain0.  Please monitor the xen-devel mailing list
+for updated information.
+\section{Xen Access Control Policy}
+This section describes the sHype/Xen access control policy in detail.
+It gives enough information to enable the reader to write custom
+access control policies and to use the available Xen policy tools. The
+policy language is expressive enough to specify most symmetric access
+relationships between domains and resources efficiently.
+The Xen access control policy consists of two policy components. The
+first component, called Chinese Wall (CHWALL) policy, controls which
+domains can run simultaneously on the same virtualized platform. The
+second component, called Simple Type Enforcement (STE) policy,
+controls the sharing between running domains, i.e., communication or
+access to shared resources. The CHWALL and STE policy components can
+be configured to run alone, however in our examples we will assume
+that both policy components are configured together since they
+complement each other. The XML policy file includes all information
+needed by Xen to enforce the policies.
+Figures~\ref{fig:acmxmlfilea} and \ref{fig:acmxmlfileb} show a fully
+functional but very simple example policy for Xen. The policy can
+distinguish two workload types \verb|CocaCola| and \verb|PepsiCo| and
+defines the labels necessary to associate domains and resources with
+one of these workload types. The XML Policy consists of four parts:
+\item policy header including the policy name
+\item Simple Type Enforcement block
+\item Chinese Wall Policy block
+\item label definition block
+01 <?xml version="1.0" encoding="UTF-8"?>
+02 <!-- Auto-generated by ezPolicy        -->
+03 <SecurityPolicyDefinition
+      xmlns="http://www.ibm.com";
+      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+      xsi:schemaLocation=
+          "http://www.ibm.com ../../security_policy.xsd ">
+04     <PolicyHeader>
+05         <PolicyName>example.chwall_ste.test</PolicyName>
+06         <Date>Wed Jul 12 17:32:59 2006</Date>
+07     </PolicyHeader>
+09     <SimpleTypeEnforcement>
+10         <SimpleTypeEnforcementTypes>
+11             <Type>SystemManagement</Type>
+12             <Type>PepsiCo</Type>
+13             <Type>CocaCola</Type>
+14         </SimpleTypeEnforcementTypes>
+15     </SimpleTypeEnforcement>
+17     <ChineseWall priority="PrimaryPolicyComponent">
+18         <ChineseWallTypes>
+19             <Type>SystemManagement</Type>
+20             <Type>PepsiCo</Type>
+21             <Type>CocaCola</Type>
+22         </ChineseWallTypes>
+24         <ConflictSets>
+25             <Conflict name="RER1">
+26                 <Type>CocaCola</Type>
+27                 <Type>PepsiCo</Type>
+28             </Conflict>
+29        </ConflictSets>
+30     </ChineseWall>
+\caption{Example XML security policy file -- Part I: Types and Rules 
+\subsection{Policy Header and Policy Name}
+Lines 1-2 (cf Figure~\ref{fig:acmxmlfilea}) include the usual XML
+header. The security policy definition starts in Line 3 and refers to
+the policy schema. The XML-Schema definition for the Xen policy can be
+found in the file
+\textit{/etc/xen/acm-security/policies/security-policy.xsd}. Examples
+for security policies can be found in the example subdirectory. The
+acm-security directory is only installed if ACM security is configured
+during installation (cf Section~\ref{subsection:acmexampleconfigure}).
+The \verb|Policy Header| spans lines 4-7. It includes a date field and
+defines the policy name \verb|example.chwall_ste.test|. It can also
+include optional fields that are not shown and are for future use (see
+schema definition).
+The policy name serves two purposes: First, it provides a unique name
+for the security policy. This name is also exported by the Xen
+hypervisor to the Xen management tools in order to ensure that both
+enforce the same policy. We plan to extend the policy name with a
+digital fingerprint of the policy contents to better protect this
+correlation.  Second, it implicitly points the xm tools to the
+location where the XML policy file is stored on the Xen system.
+Replacing the colons in the policy name by slashes yields the local
+path to the policy file starting from the global policy directory
+\verb|/etc/xen/acm-security/policies|. The last part of the policy
+name is the prefix for the XML policy file name, completed by
+\verb|-security_policy.xml|. Consequently, the policy with the name
+\verb|example.chwall_ste.test| can be found in the XML policy file
+named \verb|test-security_policy.xml| that is stored in the local
+directory \verb|example/chwall_ste| under the global policy directory.
+\subsection{Simple Type Enforcement Policy Component}
+The Simple Type Enforcement (STE) policy controls which domains can
+communicate or share resources. This way, Xen can enforce confinement
+of workload types by confining the domains running those workload
+types. The mandatory access control framework enforces its policy when
+domains access intended ways of communication or cooperation (shared
+memory, events, shared resources such as block devices). It builds on
+top of the core hypervisor isolation, which restricts the ways of
+inter-communication to those intended means.  STE does not protect or
+intend to protect from covert channels in the hypervisor or hardware;
+this is an orthogonal problem that can be mitigated by using the
+Run-time Exclusion rules described above or by fixing the problem in
+the core hypervisor.
+Xen controls sharing between domains on the resource and domain level
+because this is the abstraction the hypervisor and its management
+understand naturally. While this is coarse-grained, it is also very
+reliable and robust and it requires minimal changes to implement
+mandatory access controls in the hypervisor. It enables platform- and
+operation system-independent policies as part of a layered security
+Lines 9-15 (cf Figure~\ref{fig:acmxmlfilea}) define the Simple Type
+Enforcement policy component.  Essentially, they define the workload
+type names \verb|SystemManagement|, \verb|PepsiCo|, and
+\verb|CocaCola| that are available in the STE policy component. The
+policy rules are implicit: Xen permits a domain to communicate with
+another domain if and only if the labels of the domains share an
+common STE type.  Xen permits a domain to access a resource if and
+only if the labels of the domain and the resource share a common STE
+workload type.
+\subsection{Chinese Wall Policy Component}
+The Chinese Wall security policy interpretation of sHype enables users
+to prevent certain workloads from running simultaneously on the same
+hypervisor platform.  Run-time Exclusion rules (RER), also called
+Conflict Sets, define a set of workload types that are not permitted
+to run simultaneously. Of all the workloads specified in a Run-time
+Exclusion rule, at most one type can run on the same hypervisor
+platform at a time.  Run-time Exclusion Rules implement a less
+rigorous variant of the original Chinese Wall security component. They
+do not implement the *-property of the policy, which would require to
+restrict also types that are not part of an exclusion rule once they
+are running together with a type in an exclusion rule (please refer to
+http://www.gammassl.co.uk/topics/chinesewall.html for more information
+on the original Chinese Wall policy).
+Xen considers the \verb|ChineseWallTypes| part of the label for the
+enforcement of the Run-time Exclusion rules.  It is illegal to define
+labels including conflicting Chinese Wall types.
+Lines 17-30 (cf Figure~\ref{fig:acmxmlfilea}) define the Chinese Wall
+policy component. Lines 17-22 define the known Chinese Wall types,
+which coincide here with the STE types defined above. This usually
+holds if the criteria for sharing among domains and sharing of the
+hardware platform are the same. Lines 24-29 define one Run-time
+Exclusion rule:
+        <Conflict name="RER1">
+          <Type>CocaCola</Type>
+          <Type>PepsiCo</Type>
+        </Conflict>
+Based on this rule, Xen enforces that only one of the types
+\verb|CocaCola| or \verb|PepsiCo| will run on a single hypervisor
+platform at a time. For example, once a domain assigned a
+\verb|CocaCola| workload type is started, domains with the
+\verb|PepsiCo| type will be denied to start. When the former domain
+stops and no other domains with the \verb|CocaCola| type are running,
+then domains with the \verb|PepsiCo| type can start.
+Xen maintains reference counts on each running workload type to keep
+track of which workload types are running. Every time a domain starts
+or resumes, the reference count on those Chinese Wall types that are
+referenced in the domain's label are incremented. Every time a domain
+is destroyed or saved, the reference counts of its Chinese Wall types
+are decremented. sHype in Xen covers migration and live-migration,
+which is treated the same way as saving a domain on the source
+platform and resuming it on the destination platform.
+Reasons why users would want to restrict which workloads or domains
+can share the system hardware include:
+\item Imperfect resource management or control might enable a rogue
+  domain to starve another domain and the workload running in it.
+\item Redundant domains might run the same workload to increase
+  availability; such domains should not run on the same hardware to
+  avoid single points of failure.
+\item Imperfect Xen core domain isolation might enable two rogue
+  domains running different workload types to use unintended and
+  unknown ways (covert channels) to exchange some data. This way, they
+  bypass the policed Xen access control mechanisms.  Such
+  imperfections cannot be completely eliminated and are a result of
+  trade-offs between security and other design requirements. For a
+  simple example of a covert channel see
+  http://www.multicians.org/timing-chn.html. Such covert channels
+  exist also between workloads running on different platforms if they
+  are connected through networks. The Xen Chinese Wall policy provides
+  an approximation of this imperfect ``air-gap'' between selected
+  workload types.
+\subsection{Security Labels}
+To enable Xen to associate domains with workload types running in
+them, each domain is assigned a security label that includes the
+workload types of the domain.
+32     <SecurityLabelTemplate>
+33         <SubjectLabels bootstrap="SystemManagement">
+34             <VirtualMachineLabel>
+35                 <Name>SystemManagement</Name>
+36                 <SimpleTypeEnforcementTypes>
+37                     <Type>SystemManagement</Type>
+38                     <Type>PepsiCo</Type>
+39                     <Type>CocaCola</Type>
+40                 </SimpleTypeEnforcementTypes>
+41                 <ChineseWallTypes>
+42                     <Type>SystemManagement</Type>
+43                 </ChineseWallTypes>
+44             </VirtualMachineLabel>
+46             <VirtualMachineLabel>
+47                 <Name>PepsiCo</Name>
+48                 <SimpleTypeEnforcementTypes>
+49                     <Type>PepsiCo</Type>
+50                 </SimpleTypeEnforcementTypes>
+51                 <ChineseWallTypes>
+52                     <Type>PepsiCo</Type>
+53                 </ChineseWallTypes>
+54             </VirtualMachineLabel>
+56             <VirtualMachineLabel>
+57                 <Name>CocaCola</Name>
+58                 <SimpleTypeEnforcementTypes>
+59                     <Type>CocaCola</Type>
+60                 </SimpleTypeEnforcementTypes>
+61                 <ChineseWallTypes>
+62                     <Type>CocaCola</Type>
+63                 </ChineseWallTypes>
+64             </VirtualMachineLabel>
+65         </SubjectLabels>
+67         <ObjectLabels>
+68             <ResourceLabel>
+69                 <Name>SystemManagement</Name>
+70                 <SimpleTypeEnforcementTypes>
+71                     <Type>SystemManagement</Type>
+72                 </SimpleTypeEnforcementTypes>
+73             </ResourceLabel>
+75             <ResourceLabel>
+76                 <Name>PepsiCo</Name>
+77                 <SimpleTypeEnforcementTypes>
+78                     <Type>PepsiCo</Type>
+79                 </SimpleTypeEnforcementTypes>
+80             </ResourceLabel>
+82             <ResourceLabel>
+83                 <Name>CocaCola</Name>
+84                 <SimpleTypeEnforcementTypes>
+85                     <Type>CocaCola</Type>
+86                 </SimpleTypeEnforcementTypes>
+87             </ResourceLabel>
+88         </ObjectLabels>
+89     </SecurityLabelTemplate>
+90  </SecurityPolicyDefinition>
+\caption{Example XML security policy file -- Part II: Label Definition.}
+Lines 32-89 (cf Figure~\ref{fig:acmxmlfileb}) define the
+\verb|SecurityLabelTemplate|, which includes the labels that can be
+attached to domains and resources when this policy is active. The
+domain labels include Chinese Wall types while resource labels do not
+include Chinese Wall types. Lines 33-65 define the
+\verb|SubjectLabels| that can be assigned to domains. For example, the
+virtual machine label \verb|CocaCola| (cf lines 56-64 in
+Figure~\ref{fig:acmxmlfileb}) associates the domain that carries it
+with the workload type \verb|CocaCola|.
+The \verb|bootstrap| attribute names the label
+\verb|SystemManagement|.  Xen will assign this label to Domain0 at
+boot time. All other domains are assigned labels according to their
+domain configuration file (see
+Section~\ref{subsection:acmexamplelabeldomains} for examples of how to
+label domains). Lines 67-88 define the \verb|ObjectLabels|. Those
+labels can be assigned to resources when this policy is active.
+In general, user domains should be assigned labels that have only a
+single SimpleTypeEnforcement workload type. This way, workloads remain
+confined even if user domains become rogue. Any domain that is
+assigned a label with multiple STE types must be trusted to keep
+information belonging to the different STE types separate (confined).
+For example, Domain0 is assigned the bootstrap label
+\verb|SystemsManagement|, which includes all existing STE types.
+Therefore, Domain0 must take care not to enable unauthorized
+information flow (eg. through block devices or virtual networking)
+between domains or resources that are assigned different STE types.
+Security administrators simply use the name of a label (specified in
+the \verb|<Name>| field) to associate a label with a domain (cf.
+Section~\ref{subsection:acmexamplelabeldomains}). The types inside the
+label are used by the Xen access control enforcement.  While the name
+can be arbitrarily chosen (as long as it is unique), it is advisable
+to choose the label name in accordance to the security types included.
+While the XML representation in the above label seems unnecessary
+flexible, labels in general can consist of multiple types as we will
+see in the following example.
+Assume that \verb|PepsiCo| and \verb|CocaCola| workloads use virtual
+disks that are provided by a virtual I/O domain hosting a physical
+storage device and carrying the following label:
+        <VirtualMachineLabel>
+          <Name>VIO</Name>
+          <SimpleTypeEnforcementTypes>
+              <Type>CocaCola</Type>
+              <Type>PepsiCo</Type>
+          </SimpleTypeEnforcementTypes>
+          <ChineseWallTypes>
+              <Type>VIOServer</Type>
+          </ChineseWallTypes>
+        </VirtualMachineLabel>
+This Virtual I/O domain (VIO) exports its virtualized disks by
+communicating both to domains labeled with the \verb|PepsiCo| label
+and domains labeled with the \verb|CocaCola| label. This requires the
+VIO domain to carry both the STE types \verb|CocaCola| and
+\verb|PepsiCo|. In this example, the confinement of \verb|CocaCola|
+and \verb|PepsiCo| workload depends on a VIO domain that must keep the
+data of those different workloads separate. The virtual disks are
+labeled as well (see Section~\ref{subsection:acmexamplelabelresources}
+for labeling resources) and enforcement functions inside the VIO
+domain must ensure that the labels of the domain mounting a virtual
+disk and the virtual disk label share a common STE type. The VIO label
+carrying its own VIOServer CHWALL type introduces the flexibility to
+permit the trusted VIO server to run together with CocaCola or PepsiCo
+Alternatively, a system that has two hard-drives does not need a VIO
+domain but can directly assign one hardware storage device to each of
+the workloads (if the platform offers an IO-MMU, cf
+Section~\ref{s:ddsecurity}.  Sharing hardware through virtualization
+is a trade-off between the amount of trusted code (size of the trusted
+computing base) and the amount of acceptable over-provisioning. This
+holds both for peripherals and for system platforms.
+\subsection{Tools For Creating sHype/Xen Security Policies}
+To create a security policy for Xen, you can use one of the following
+\item \verb|ezPolicy| GUI tool -- start writing policies
+\item \verb|xensec_gen| tool -- refine policies created with \verb|ezPolicy|
+\item text or XML editor
+We use the \verb|ezPolicy| tool in
+Section~\ref{subsection:acmexamplecreate} to quickly create a workload
+protection policy. If desired, the resulting XML policy file can be
+loaded into the \verb|xensec_gen| tool to refine it. It can also be
+directly edited using an XML editor. Any XML policy file is verified
+against the security policy schema when it is translated (see
+\section{Current Limitations}
+The sHype/ACM configuration for Xen is work in progress. There is
+ongoing work for protecting virtualized resources and planned and
+ongoing work for protecting access to remote resources and domains.
+The following sections describe limitations of some of the areas into
+which access control is being extended.
+\subsection{Network Traffic}
+Local and remote network traffic is currently not controlled.
+Solutions to add sHype/ACM policy enforcement to the virtual network
+exist but need to be discussed before they can become part of Xen.
+Subjecting external network traffic to the ACM security policy is work
+in progress. Manually setting up filters in domain 0 is required for
+now but does not scale well.
+\subsection{Resource Access and Usage Control}
+Enforcing the security policy across multiple hypervisor systems and
+on access to remote shared resources is work in progress. Extending
+access control to new types of resources is ongoing work (e.g. network
+On a single Xen system, information about the association of resources
+and security labels is stored in
+\verb|/etc/xen/acm-security/policy/resource_labels|. This file relates
+a full resource path with a security label. This association is weak
+and will break if resources are moved or renamed without adapting the
+label file. Improving the protection of label-resource relationships
+is ongoing work.
+Controlling resource usage and enforcing resource limits in general is
+ongoing work in the Xen community.
+\subsection{Domain Migration}
+Labels on domains are enforced during domain migration and the
+destination hypervisor will ensure that the domain label is valid and
+the domain is permitted to run (considering the Chinese Wall policy
+rules) before it accepts the migration.  However, the network between
+the source and destination hypervisor as well as both hypervisors must
+be trusted. Architectures and prototypes exist that both protect the
+network connection and ensure that the hypervisors enforce access
+control consistently but patches are not yet available for the main
+\subsection{Covert Channels}
+The sHype access control aims at system independent security policies.
+It builds on top of the core hypervisor isolation. Any covert channels
+that exist in the core hypervisor or in the hardware (e.g., shared
+processor cache) will be inherited. If those covert channels are not
+the result of trade-offs between security and other system properties,
+then they are most effectively minimized or eliminated where they are
+caused. sHype offers however some means to mitigate their impact
+(cf. run-time exclusion rules).
 %% Chapter Build and Boot Options

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.