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/
Home Products Support Community News


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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] PATCH [1/4] sHype/ACM User Guide Chapter
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Mon, 31 Jul 2006 09:31:41 -0400
Delivery-date: Mon, 31 Jul 2006 06:32:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
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
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] PATCH [1/4] sHype/ACM User Guide Chapter, Reiner Sailer <=