Remove unmaintained Access Control Module (ACM) from hypervisor.

Signed-off-by: Keir Fraser <keir@xen.org>

2 files changed, 0 insertions, 1962 deletions

diff --git a/docs/src/interface.tex b/docs/src/interface.tex
index e596b63535..6f81ead684 100644
--- a/docs/src/interface.tex
+++ b/docs/src/interface.tex
@@ -2177,47 +2177,6 @@ Most of the above are best understood by looking at the code
 implementing them (in {\tt xen/common/dom0\_ops.c}) and in 
 the user-space tools that use them (mostly in {\tt tools/libxc}). 
 
-\section{Access Control Module Hypercalls}
-\label{s:acmops}
-
-Hypercalls relating to the management of the Access Control Module are
-also restricted to domain 0 access for now. For more details on any or
-all of these, please see {\tt xen/include/public/acm\_ops.h}.  A
-complete list is given below:
-
-\begin{quote}
-
-\hypercall{acm\_op(int cmd, void *args)}
-
-This hypercall can be used to configure the state of the ACM, query
-that state, request access control decisions and dump additional
-information.
-
-\begin{description}
-
-\item [ACMOP\_SETPOLICY:] set the access control policy
-
-\item [ACMOP\_GETPOLICY:] get the current access control policy and
-  status
-
-\item [ACMOP\_DUMPSTATS:] get current access control hook invocation
-  statistics
-
-\item [ACMOP\_GETSSID:] get security access control information for a
-  domain
-
-\item [ACMOP\_GETDECISION:] get access decision based on the currently
-  enforced access control policy
-
-\end{description}
-\end{quote}
-
-Most of the above are best understood by looking at the code
-implementing them (in {\tt xen/common/acm\_ops.c}) and in the
-user-space tools that use them (mostly in {\tt tools/security} and
-{\tt tools/python/xen/lowlevel/acm}).
-
-
 \section{Debugging Hypercalls} 
 
 A few additional hypercalls are mainly useful for debugging: 
diff --git a/docs/src/user.tex b/docs/src/user.tex
index 69971cdd66..a35bb86b88 100644
--- a/docs/src/user.tex
+++ b/docs/src/user.tex
@@ -2081,1927 +2081,6 @@ iptables:
 iptables -A INPUT -p tcp -{}-destination-port 8002 -j REJECT
 \end{verbatim}
 
-%% 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 Domain-0 (cf previous chapter).
-
-Benefits of configuring sHype/ACM in Xen include:
-\begin{itemize}
-\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
-\end{itemize}
-
-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 most operating systems, are not effective against viruses or
-misbehaving programs.)  Where mandatory access control exists (e.g.,
-SELinux), they usually deploy platform-specific, complex, and difficult
-to understand security policies.  Multi-tier applications in business
-environments typically require different operating systems
-(e.g., AIX, Windows, Linux) in different tiers. 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 and consistent security layer and safety net across
-different platforms and operating systems.
-
-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 storage 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 by user domains and are effective even
-against compromised or rogue domains.
-
-\section{Overview}
-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
-Section~\ref{section:acmexample}.
-
-\begin{figure}
-\centering
-\includegraphics[width=13cm]{figs/acm_overview.eps}
-\caption{Overview of activating sHype workload protection in Xen.
-  Section numbers point to representative examples.}
-\label{fig:acmoverview}
-\end{figure}
-
-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 decide about access requests. Workload types are represented by
-security labels that can be securely associated to domains and resources (cf
-Subsections~\ref{subsection:acmexamplelabeldomains}
-and~\ref{subsection:acmexamplelabelresources}).  The functioning of
-the active sHype/Xen workload protection is demonstrated using simple
-resource assignment, and domain creation tests in
-Subsection~\ref{subsection:acmexampletest}.
-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 you create your own sHype 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
-Xen users and developers 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}
-\label{section:acmexample}
-
-You are about to configure and deploy the Xen sHype workload protection
-by following 5 simple steps:
-\begin{itemize}
-\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
-\end{itemize}
-The essential commands to create and deploy an 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
-order.
-
-\subsection{Configuring/Building sHype Support into Xen}
-\label{subsection:acmexampleconfigure}
-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.
-
-\begin{verbatim}
-  (1) In Config.mk
-        Change: XSM_ENABLE ?= n
-            To: XSM_ENABLE ?= y
-
-        Change: ACM_SECURITY ?= n
-            To: ACM_SECURITY ?= y
-\end{verbatim}
-
-Then install the security-enabled Xen environment as follows:
-
-\begin{verbatim}
-  (2) # make world
-      # make install
-\end{verbatim}
-
-Reboot into the security-enabled Xen hypervisor.
-
-\begin{verbatim}
-  (3) # reboot
-\end{verbatim}
-
-Xen will boot into the default security policy. After reboot,
-you can explore the simple DEFAULT policy.
-\begin{scriptsize}
-\begin{verbatim}
-# xm getpolicy
-Supported security subsystems   : ACM
-Policy name           : DEFAULT
-Policy type           : ACM
-Version of XML policy : 1.0
-Policy configuration  : loaded
-
-# xm labels
-SystemManagement
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-Domain-0   0   941     1     r-----     38.1  ACM:DEFAULT:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-In this state, no domains can be started.
-Now, a policy can be created and loaded into the hypervisor.
-
-\subsection{Creating A WLP Policy in 3 Simple Steps with ezPolicy}
-\label{subsection:acmexamplecreate}
-
-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 Domain-0, 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:
-
-\begin{verbatim}
-  (4) # xensec_ezpolicy
-\end{verbatim}
-
-Figure~\ref{fig:acmezpolicy} shows a screen-shot of the tool. The
-following steps illustrate how you can create the workload definition
-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:
-\begin{enumerate}
-\item defining workloads
-\item defining run-time conflicts
-\item translating the workload definition into an sHype/Xen access
-  control policy
-\end{enumerate}
-
-\paragraph{Defining workloads.} Workloads are defined for each
-organization and department that you enter in the left panel.
-
-To ease the transition from an unlabeled to a fully labeled workload-protection
-environment, we have added support to sHype/Xen to run unlabeled domains accessing
-unlabeled resources in addition to labeled domains accessing labeled resources.
-
-Support for running unlabeled domains on sHype/Xen is enabled by adding the
-predefined workload type and label \verb|__UNLABELED__| to the security
-policy. (This is a double underscore
-followed by the string ''\verb|UNLABELED|'' followed by a double underscore.)
-The ezPolicy tool automatically adds this organization-level workload type
-to a new workload definition (cf Figure~\ref{fig:acmezpolicy}). It can simply be
-deleted from the workload definition if no such support is desired. If unlabeled domains
-are supported in the policy, then any domain or resource that has no label will implicitly
-inherit this label when access control decisions are made. In effect, unlabeled
-domains and resources define a new workload type \verb|__UNLABELED__|, which is
-confined from any other labeled workload.
-
-Please use now the ``New Org'' button to add the organization workload types
-``A-Bank'', ``B-Bank'', and ``AutoCorp''.
-
-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 ``SecurityUnderwriting'',
-and ``MarketAnalysis'' for the ``A-Bank''. The resulting layout of the
-tool should be similar to the left panel shown in
-Figure~\ref{fig:acmezpolicy}.
-
-\begin{figure}[htb]
-\centering
-\includegraphics[width=13cm]{figs/acm_ezpolicy_gui.eps}
-\caption{Final layout including workload definition and Run-time Exclusion rules.}
-\label{fig:acmezpolicy}
-\end{figure}
-
-\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. Cautious users should include the \verb|__UNLABELED__|
-workload type in all run-time exclusion rules because any workload
-could run inside unlabeled domains.
-
-To prevent A-Bank and B-Bank workloads (including their
-departmental workloads) from running simultaneously on the same
-hypervisor system, select the organization ``A-Bank'' and, while
-pressing the \verb|<CTRL>|-key, select the organization ``B-Bank''.
-Being cautious, we also prevent unlabeled workloads from running with
-any of those workloads by pressing the \verb|<CTRL>|-key and selecting
-``\_\_UNLABELED\_\_''. Now press the button 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 access control decisions.
-
-Please repeat this process to create another run-time exclusion rule
-for the department workloads ``A-Bank.SecurityUnderwriting'',
-``A-Bank.MarketAnalysis''. Also add the ``\_\_UNLABELED\_\_''
-workload type to this conflict set.
-
-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.
-This workload definition can be later refined if required.
-
-\paragraph{Translating the workload definition into an 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. Enter the following policy
-name in the popup window: \verb|mytest|. If you are running ezPolicy in
-Domain-0, the resulting policy file mytest\_security-policy.xml will
-automatically be placed into the right directory (/etc/xen/acm-security/policies/).
-If you run the tool on another system, then you need to copy the
-resulting policy file into Domain-0 before continuing.  See
-Section~\ref{subsection:acmnaming} for naming conventions of security
-policies.
-
-\begin{scriptsize}
-\textbf{Note:} The support for \verb|__UNLABELED__| domains and
-resources is meant to help transitioning from an uncontrolled
-environment to a workload-protected environment by starting with
-unlabeled domains and resources and then step-by-step labeling domains
-and resources. Once all workloads are labeled, the \verb|__UNLABELED__|
-type can simply be removed from the Domain-0 label or from the policy
-through a policy update. Section~\ref{subsection:acmpolicymanagement} will
-show how unlabeled domains can be disabled by updating the
-\verb|mytest| policy at run-time.
-\end{scriptsize}
-
-\subsection{Deploying a WLP Policy}
-\label{subsection:acmexampleinstall}
-To deploy the workload protection policy we created in
-Section~\ref{subsection:acmexamplecreate}, we create a policy
-representation (mytest.bin), load it into the Xen
-hypervisor, and configure Xen to also load this policy during
-reboot.
-
-The following command translates the source policy representation
-into a format that can be loaded into Xen with sHype/ACM support,
-activates the policy, and configures this policy for future boot
-cycles into the boot sequence. Please refer to the \verb|xm|
-man page for further details:
-
-\begin{verbatim}
-  (5) # xm setpolicy ACM mytest
-      Successfully set the new policy.
-      Supported security subsystems   : ACM
-      Policy name           : mytest
-      Policy type           : ACM
-      Version of XML policy : 1.0
-      Policy configuration  : loaded, activated for boot
-\end{verbatim}
-
-Alternatively, if installing the policy fails (e.g., because it cannot
-identify the Xen boot entry), you can manually install the policy in 3
-steps a-c.
-
-(\textit{Alternatively to 5 - step a}) Manually copy the policy binary
-file into the boot directory:
-
-\begin{scriptsize}
-\begin{verbatim}
-# cp /etc/xen/acm-security/policies/mytest.bin /boot/mytest.bin
-\end{verbatim}
-\end{scriptsize}
-
-(\textit{Alternatively to 5 - step b}) Manually add a module line to your
-Xen boot entry so that grub loads this policy file during startup:
-
-\begin{scriptsize}
-\begin{verbatim}
-title XEN Devel with 2.6.18.8
-     kernel /xen.gz
-     module /vmlinuz-2.6.18.8-xen root=/dev/sda3 ro console=tty0
-     module /initrd-2.6.18.8-xen.img
-     module /mytest.bin
-\end{verbatim}
-\end{scriptsize}
-
-(\textit{Alternatively to 5 - step c}) Reboot. Xen will choose the
-bootstrap label defined in the policy as Domain-0 label during reboot.
-After reboot, you can re-label Domain-0 at run-time,
-cf Section~\ref{subsection:acmlabeldom0}.
-
-Assuming that command (5) succeeded or you followed the alternative
-instructions above, you should see the new policy and label appear
-when listing domains:
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm list --label
-Name      ID   Mem VCPUs     State   Time(s) Label
-Domain-0   0   941     1     r-----    81.5  ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-If the security label at the end of the line says ``INACTIVE'' then the
-security is not enabled. Verify the previous steps. Note: Domain-0 is
-assigned a default label (see \verb|bootstrap| policy attribute
-explained in Section~\ref{section:acmpolicy}). All other domains must
-be explicitly labeled, which we describe in detail below.
-
-\subsection{Labeling Unmanaged User Domains}
-\label{subsection:acmexamplelabeldomains}
-
-Unmanaged domains are started in Xen by using a configuration
-file. Please refer to Section~\ref{subsection:acmlabelmanageddomains}
-if you are using managed domains.
-
-The following configuration file defines \verb|domain1|:
-
-\begin{scriptsize}
-\begin{verbatim}
-# cat domain1.xm
-kernel= "/boot/vmlinuz-2.6.18.8-xen"
-memory = 128
-name = "domain1"
-vif = ['']
-dhcp = "dhcp"
-disk = ['file:/home/xen/dom_fc5/fedora.fc5.img,sda1,w', \
-        'file:/home/xen/dom_fc5/fedora.fc5.swap,sda2,w']
-root = "/dev/sda1 ro xencons=tty"
-\end{verbatim}
-\end{scriptsize}
-
-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. Our \verb|mytest| policy is configured so that Xen
-assigns a default label \verb|__UNLABELED__| to domains and resources that
-have no label and supports them in a controlled manner. Since neither the domain,
-nor the resources are (yet) labeled, this domain can start under the \verb|mytest|
-policy:
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm create domain1.xm
-Using config file "./domain1.xm".
-Started domain domain1
-
-# xm list --label
-Name     ID   Mem VCPUs      State   Time(s) Label
-domain1   1   128     1     -b----      0.7  ACM:mytest:__UNLABELED__
-Domain-0  0   875     1     r-----     84.6  ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-Please shutdown domain1 so that we can move it into the protection
-domain of workload \verb|A-Bank|.
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm shutdown domain1
-(wait some seconds until the domain has shut down)
-
-#xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-Domain-0   0   875     1     r-----     86.4  ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-We assume that the processing in domain1 contributes to the \verb|A-Bank| workload.
-We explore now how to transition this domain into the ``A-Bank'' workload-protection.
-The following command prints all domain labels available in the active policy:
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm labels
-A-Bank
-A-Bank.MarketAnalysis
-A-Bank.SecurityUnderwriting
-AutoCorp
-B-Bank
-SystemManagement
-__UNLABELED__
-\end{verbatim}
-\end{scriptsize}
-
-Now label \verb|domain1| with the A-Bank label and another \verb|domain2|
-with the B-Bank label. Please refer to the xm man page for
-further information.
-
-\begin{verbatim}
-  (6) # xm addlabel A-Bank dom domain1.xm
-      # xm addlabel B-Bank dom domain2.xm
-\end{verbatim}
-
-Let us try to start the domain again:
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm create domain1.xm
-Using config file "./domain1.xm".
-Error: VM's access to block device 'file:/home/xen/dom_fc5/fedora.fc5.img' denied
-\end{verbatim}
-\end{scriptsize}
-
-This error indicates that \verb|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
-resources.
-
-\subsection{Labeling Resources}
-\label{subsection:acmexamplelabelresources}
-You can use the \verb|xm labels type=res| command to list available
-resource labels. Let us assign the A-Bank resource label to the
-\verb|domain1| image file representing \verb|/dev/sda1| and to its swap file:
-
-\begin{verbatim}
-  (7) # xm addlabel A-Bank res \
-      file:/home/xen/dom_fc5/fedora.fc5.img
-
-      # xm addlabel A-Bank res \
-      file:/home/xen/dom_fc5/fedora.fc5.swap
-\end{verbatim}
-
-The following command lists all labeled resources on the system, e.g.,
-to lookup or verify the labeling:
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm resources
-file:/home/xen/dom_fc5/fedora.fc5.swap
-      type: ACM
-    policy: mytest
-     label: A-Bank
-file:/home/xen/dom_fc5/fedora.fc5.img
-      type: ACM
-    policy: mytest
-     label: A-Bank
-\end{verbatim}
-\end{scriptsize}
-
-Starting \verb|domain1| will now succeed:
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm create domain1.xm
-Using config file "./domain1.xm".
-Started domain domain1
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1    3   128     1     -b----      0.8  ACM:mytest:A-Bank
-Domain-0   0   875     1     r-----     90.9  ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-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|rmlabel| and \verb|addlabel|
-respectively.  Please see Section~\ref{section:acmlimitations} for
-further details.
-
-\begin{verbatim}
-  (8) Label the resources of domain2 as B-Bank
-      but please do not start this domain yet.
-\end{verbatim}
-
-\subsection{Testing The Xen Workload Protection}
-\label{subsection:acmexampletest}
-
-We are about to demonstrate the sHype/Xen workload protection by verifying
-\begin{itemize}
-\item that user domains with conflicting workloads cannot run
-  simultaneously
-\item that user domains cannot access resources of workloads other than the
-	one they are associated with
-\item that user domains cannot exchange network packets if they are not
-  associated with the same workload type (not yet supported in Xen)
-\end{itemize}
-
-\paragraph{Test 1: Run-time exclusion rules.} We assume that \verb|domain1|
-with the A-Bank label is still running. While \verb|domain1| is running,
-the run-time exclusion set of our policy implies that \verb|domain2| cannot
-start because the label of \verb|domain1| includes the CHWALL type A-Bank
-and the label of \verb|domain2| includes the CHWALL type B-Bank. The
-run-time exclusion rule of our policy enforces that A-Bank and
-B-Bank cannot run at the same time on the same hypervisor platform.
-Once domain1 is stopped, saved, or migrated to another platform,
-\verb|domain2| can start. Once \verb|domain2| is started, however,
-\verb|domain1| can no longer start or resume on this system. When creating the
-Chinese Wall types for the workload labels, the ezPolicy tool policy
-translation component ensures that department workloads inherit all the
-organization types (and with it any organization exclusions).
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1    3   128     1     -b----      0.8  ACM:mytest:A-Bank
-Domain-0   0   875     1     r-----     90.9  ACM:mytest:SystemManagement
-
-# xm create domain2.xm
-Using config file "./domain2.xm".
-Error: 'Domain in conflict set with running domains'
-
-# xm shutdown domain1
-(wait some seconds until domain 1 is shut down)
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-Domain-0   0   873     1     r-----     95.3  ACM:mytest:SystemManagement
-
-# xm create domain2.xm
-Using config file "./domain2.xm".
-Started domain domain2
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain2    5   164     1     -b----      0.3  ACM:mytest:B-Bank
-Domain-0   0   839     1     r-----     96.4  ACM:mytest:SystemManagement
-
-# xm create domain1.xm
-Using config file "domain1.xm".
-Error: 'Domain in conflict with running domains'
-
-# xm shutdown domain2
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-Domain-0   0   839     1     r-----     97.8  ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-You can verify that domains with AutoCorp label can run together with
-domains labeled A-Bank or B-Bank.
-
-\paragraph{Test2: Resource access.} In this test, we will re-label the
-swap file for \verb|domain1| with the \verb|B-Bank| resource label. In a
-real environment, the swap file must be sanitized (scrubbed/zeroed) before
-it is reassigned to prevent data leaks from the A-Bank to the B-Bank workload
-through the swap file.
-
-We expect that \verb|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.
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm rmlabel res file:/home/xen/dom_fc5/fedora.fc5.swap
-
-# xm addlabel B-Bank res file:/home/xen/dom_fc5/fedora.fc5.swap
-
-# xm resources
-file:/home/xen/dom_fc5/fedora.fc5.swap
-      type: ACM
-    policy: mytest
-     label: B-Bank
-file:/home/xen/dom_fc5/fedora.fc5.img
-      type: ACM
-    policy: mytest
-     label: A-Bank
-
-# xm create domain1.xm
-Using config file "./domain1.xm".
-Error:
-VM's access to block device 'file:/home/xen/dom_fc5/fedora.fc5.swap' denied
-\end{verbatim}
-\end{scriptsize}
-
-The resource authorization checks are performed before the domain is actually started
-so that failures during the startup are prevented. A domain is only started if all
-the resources specified in its configuration are accessible.
-
-\paragraph{Test 3: Communication.} In this test we would verify that
-two domains with labels A-Bank and B-Bank 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 Domain-0 virtual network. We
-are working on the sHype/ACM controls for local and remote network
-traffic through Domain-0. Please monitor the xen-devel mailing list
-for updated information.
-
-
-\subsection{Labeling Domain-0 --or-- Restricting System Authorization}
-\label{subsection:acmlabeldom0}
-The major use case for explicitly labeling or relabeling Domain-0 is to restrict
-or extend which workload types can run on a virtualized Xen system. This enables
-flexible partitioning of the physical infrastructure as well as the workloads
-running on it in a multi-platform environment.
-
-In case no Domain-0 label is explicitly stated, we automatically assigned Domain-0
-the \verb|SystemManagement| label, which includes all STE (workload) types that
-are known to the policy. In effect, the Domain-0 label authorizes the Xen system
-to run only those workload types, whose STE types are included in the Domain-0
-label. Hence, choosing the \verb|SystemManagement| label for Domain-0 permits any
-labeled domain to run. Resetting the label for Domain-0 at boot or run-time to
-a label with a subset of the known STE workload types restricts which user domains
-can run on this system. If Domain-0 is relabeled at run-time, then the new label
-must at least include all STE types of those domains that are currently running.
-The operation fails otherwise. This requirement ensures that the system remains
-in a valid security configuration after re-labelling.
-
-Restricting the Domain-0 authorization through the label creates a flexible
-policy-driven way to strongly partition the physical infrastructure and the
-workloads running on it. This partitioning will be automatically enforced during
-migration, start, or resume of domains and simplifies the security management
-considerably. Strongly competing workloads can be forced to run on separate physical
-infrastructure and become less depend on the domain isolation capabilities
-of the hypervisor.
-
-First, we relabel the swap image back to A-Bank and then start up domain1:
-\begin{scriptsize}
-\begin{verbatim}
-# xm rmlabel res file:/home/xen/dom_fc5/fedora.fc5.swap
-
-# xm addlabel A-Bank res file:/home/xen/dom_fc5/fedora.fc5.swap
-
-# xm create domain1.xm
-Using config file "./domain1.xm".
-Started domain domain1
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1    7   128     1     -b----      0.7  ACM:mytest:A-Bank
-Domain-0   0   839     1     r-----    103.1  ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-The following command will restrict the Xen system to only run STE types
-included in the A-Bank label.
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm addlabel A-Bank mgt Domain-0
-Successfully set the label of domain 'Domain-0' to 'A-Bank'.
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-Domain-0   0   839     1     r-----    103.7  ACM:mytest:A-Bank
-domain1    7   128     1     -b----      0.7  ACM:mytest:A-Bank
-
-\end{verbatim}
-\end{scriptsize}
-
-In our example policy in Figure~\ref{fig:acmxmlfileb}, this means that
-only \verb|A-Bank| domains and workloads (types) can run after the
-successful completion of this command because the \verb|A-Bank| label
-includes only a single STE type, namely \verb|A-Bank|. This command
-fails if any running domain has an STE type in its label that is not
-included in the A-Bank label.
-
-If we now label a domain3 with AutoCorp, it cannot start because Domain-0 is
-no longer authorized to run the workload type \verb|AutoCorp|.
-\begin{scriptsize}
-\begin{verbatim}
-# xm addlabel AutoCorp dom domain3.xm
-  (remember to label its resources, too)
-
-# xm create domain3.xm
-Using config file "./domain3.xm".
-Error: VM is not authorized to run.
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-Domain-0   0   839     1     r-----    104.7  ACM:mytest:A-Bank
-domain1    7   128     1     -b----      0.7  ACM:mytest:A-Bank
-\end{verbatim}
-\end{scriptsize}
-
-At this point, unlabeled domains cannot start either. Let domain4.xm
-describe an unlabeled domain, then trying to start domain4
-will fail:
-\begin{scriptsize}
-\begin{verbatim}
-# xm getlabel dom domain4.xm
-Error: 'Domain not labeled'
-
-# xm create domain4.xm
-Using config file "./domain4.xm".
-Error: VM is not authorized to run.
-\end{verbatim}
-\end{scriptsize}
-
-Relabeling Domain-0 with the SystemManagement label will enable domain3 to start.
-\begin{scriptsize}
-\begin{verbatim}
-# xm addlabel SystemManagement mgt Domain-0
-Successfully set the label of domain 'Domain-0' to 'SystemManagement'.
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1    7   128     1     -b----      0.8  ACM:mytest:A-Bank
-Domain-0   0   839     1     r-----    106.6  ACM:mytest:SystemManagement
-
-# xm create domain3.xm
-Using config file "./domain3.xm".
-Started domain domain3
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1    7   128     1     -b----      0.8 ACM:mytest:A-Bank
-domain3    8   164     1     -b----      0.3 ACM:mytest:AutoCorp
-Domain-0   0   711     1     r-----    107.6 ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-
-\subsection{Labeling Managed User Domains}
-\label{subsection:acmlabelmanageddomains}
-
-Xend has been extended with functionality to manage domains along with their
-configuration information. Such domains are configured and started via Xen-API
-calls. Since managed domains do not have an associated xm configuration file,
-the existing \verb|addlabel| command, which adds the security label into a
-domain's configuration file, will not work for such managed domains.
-
-Therefore, we have extended the \verb|xm addlabel| and \verb|xm rmlabel|
-subcommands to enable adding security labels to and removing security
-labels from managed domain configurations. The following example shows how
-the \verb|A-Bank| label can be assigned to the xend-managed
-domain configuration of \verb|domain1|. Removing labels from managed user
-domain configurations works similarly.
-
-Below, we show a dormant configuration of the managed domain1
-with ID \verb|"-1"| and state \verb|"-----"| before labeling:
-\begin{scriptsize}
-\begin{verbatim}
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1   -1   128     1     ------      0.0 ACM:mytest:__UNLABELED__
-Domain-0   0   711     1     r-----    128.4 ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-Now we label the managed domain:
-\begin{scriptsize}
-\begin{verbatim}
-# xm addlabel A-Bank mgt domain1
-Successfully set the label of the dormant domain 'domain1' to 'A-Bank'.
-\end{verbatim}
-\end{scriptsize}
-
-After labeling, you can see that the security label is part of the
-domain configuration:
-\begin{scriptsize}
-\begin{verbatim}
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1   -1   128     1     ------      0.0  ACM:mytest:A-Bank
-Domain-0   0   711     1     r-----    129.7  ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-This command extension does not support relabeling of individual running user domains
-for several reasons. For one, because of the difficulty to revoke resources
-in cases where a running domain's new label does not permit access to resources
-that were accessible under the old label. Another reason is that changing the
-label of a single domain of a workload is rarely a good choice and will affect
-the workload isolation properties of the overall workload.
-
-However, the name and contents of the label associated with running domains can
-be indirectly changed through a global policy change, which will update the whole
-workload consistently (domains and resources), cf.
-Section~\ref{subsection:acmpolicymanagement}.
-
-\section{Xen Access Control Policy}
-\label{section:acmpolicy}
-
-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 Simple Type Enforcement (STE) policy, controls
-the sharing between running domains, i.e., communication or access to
-shared resources. The second component, called Chinese Wall (CHWALL)
-policy, controls which domains can run simultaneously on the same
-virtualized platform. The CHWALL and STE policy components complement
-each other. The XML policy file includes all information
-needed by Xen to enforce those policies.
-
-Figures~\ref{fig:acmxmlfilea} and \ref{fig:acmxmlfileb} show the fully
-functional but very simple example Xen security policy that is created
-by ezPolicy as shown in Figure~\ref{fig:acmezpolicy}. The policy can
-distinguish the 6 workload types shown in lines 11-17 in
-Fig.~\ref{fig:acmxmlfilea}. The whole XML Security Policy consists of
-four parts:
-\begin{enumerate}
-\item Policy header including the policy name
-\item Simple Type Enforcement block
-\item Chinese Wall Policy block
-\item Label definition block
-\end{enumerate}
-
-\begin{figure}
-\begin{scriptsize}
-\begin{verbatim}
-01  <?xml version="1.0" ?>
-02  <!-- Auto-generated by ezPolicy        -->
-03  <SecurityPolicyDefinition ...">
-04      <PolicyHeader>
-05          <PolicyName>mytest</PolicyName>
-06          <Date>Mon Nov 19 22:51:56 2007</Date>
-07          <Version>1.0</Version>
-08      </PolicyHeader>
-09      <SimpleTypeEnforcement>
-10          <SimpleTypeEnforcementTypes>
-11              <Type>SystemManagement</Type>
-12              <Type>__UNLABELED__</Type>
-13              <Type>A-Bank</Type>
-14              <Type>A-Bank.SecurityUnderwriting</Type>
-15              <Type>A-Bank.MarketAnalysis</Type>
-16              <Type>B-Bank</Type>
-17              <Type>AutoCorp</Type>
-18          </SimpleTypeEnforcementTypes>
-19      </SimpleTypeEnforcement>
-20      <ChineseWall priority="PrimaryPolicyComponent">
-21          <ChineseWallTypes>
-22              <Type>SystemManagement</Type>
-23              <Type>__UNLABELED__</Type>
-24              <Type>A-Bank</Type>
-25              <Type>A-Bank.SecurityUnderwriting</Type>
-26              <Type>A-Bank.MarketAnalysis</Type>
-27              <Type>B-Bank</Type>
-28              <Type>AutoCorp</Type>
-29          </ChineseWallTypes>
-30          <ConflictSets>
-31              <Conflict name="RER">
-32                  <Type>A-Bank</Type>
-33                  <Type>B-Bank</Type>
-34                  <Type>__UNLABELED__</Type>
-35              </Conflict>
-36              <Conflict name="RER">
-37                  <Type>A-Bank.MarketAnalysis</Type>
-38                  <Type>A-Bank.SecurityUnderwriting</Type>
-39                  <Type>__UNLABELED__</Type>
-40              </Conflict>
-41         </ConflictSets>
-42      </ChineseWall>
-\end{verbatim}
-\end{scriptsize}
-\caption{Example XML security policy file -- Part I: Types and Rules Definition.}
-\label{fig:acmxmlfilea}
-\end{figure}
-
-\subsection{Policy Header and Policy Name}
-\label{subsection:acmnaming}
-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-8. It includes a date field and
-defines the policy name \verb|mytest| as well
-as the version of the XML. 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
-the Xen hypervisor and Domain-0 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|. Our example policy with the name
-\verb|mytest| can be found in the XML policy file named
-\verb|mytest-security_policy.xml| that is stored under the global
-policy directory. Another, preinstalled example policy named
-\verb|example.test| can be found in the \verb|test-security_policy.xml|
-under \verb|/etc/xen/acm-security/policies/example|.
-
-\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 and their resources. The mandatory access control framework
-enforces its policy when
-domains access intended communication or cooperation means (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 leading
-to those covert channels in the core hypervisor or hardware platform.
-
-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
-operating system-independent policies as part of a layered security
-approach.
-
-Lines 11-17 (cf Figure~\ref{fig:acmxmlfilea}) define the Simple Type
-Enforcement policy component.  Essentially, they define the workload
-type names \verb|SystemManagement|, \verb|A-Bank|,
-\verb|AutoCorp| etc. that are available in the STE policy component. The
-policy rules are implicit: Xen permits two domains to communicate with
-each other if and only if their security labels have at least one STE type in
-common.  Similarly, Xen permits a user domain to access a
-resource if and only if the labels of the domain and the resource
-have at least one STE workload type in common.
-
-\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 or Anti-Collocation rules, define a set of workload types
-that are not permitted to run simultaneously on the same virtualized
-platform. 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
-(http://www.gammassl.co.uk/topics/chinesewall.html provides 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 20-41 (cf Figure~\ref{fig:acmxmlfilea}) define the Chinese Wall
-policy component. Lines 22-28 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 30-41 define one Run-time
-Exclusion rules, the first of which is depicted below:
-
-\begin{scriptsize}
-\begin{verbatim}
-31  <Conflict name="RER">
-32    <Type>A-Bank</Type>
-33    <Type>B-Bank</Type>
-34    <Type>__UNLABELED__</Type>
-35  </Conflict>
-\end{verbatim}
-\end{scriptsize}
-
-Based on this rule, Xen enforces that only one of the types
-\verb|A-Bank|, \verb|B-Bank|, or \verb|__UNLABELED__| will run
-on a single hypervisor platform at a time. For example, once a domain assigned a
-\verb|A-Bank| workload type is started, domains with the
-\verb|B-Bank| type or unlabeled domains will be denied to start.
-When the former domain stops and no other domains with the \verb|A-Bank|
-type are running, then domains with the \verb|B-Bank| type or unlabeled domains
-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 fully supports migration and live-migration,
-which is subject to access control the same way as saving a domain on
-the source platform and resuming it on the destination platform.
-
-Here are some reasons why users might want to restrict workloads or domains
-from sharing the system hardware simultaneously:
-
-\begin{itemize}
-\item Imperfect resource management or control might enable a compromised
-  user domain to starve other domains and the workload running in them.
-\item Redundant user 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 bits of information.
-  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 approximated ``air-gap'' between selected workload types.
-\end{itemize}
-
-\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.
-
-\begin{figure}[htb]
-		\begin{tabular*}{\textwidth}{@{\extracolsep{\fill}}l|l}
-		\begin{minipage}{0.475\textwidth}
-		\begin{tiny}
-		\begin{verbatim}
-<SecurityLabelTemplate>
-  <SubjectLabels bootstrap="SystemManagement">
-  <VirtualMachineLabel>
-    <Name>SystemManagement</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>SystemManagement</Type>
-      <Type>__UNLABELED__</Type>
-      <Type>A-Bank</Type>
-      <Type>A-Bank.SecurityUnderwriting</Type>
-      <Type>A-Bank.MarketAnalysis</Type>
-      <Type>B-Bank</Type>
-      <Type>AutoCorp</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>SystemManagement</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name>__UNLABELED__</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>__UNLABELED__</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>__UNLABELED__</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name>A-Bank</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>A-Bank</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name>A-Bank.SecurityUnderwriting</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank.SecurityUnderwriting</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>A-Bank</Type>
-      <Type>A-Bank.SecurityUnderwriting</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name>A-Bank.MarketAnalysis</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank.MarketAnalysis</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>A-Bank</Type>
-      <Type>A-Bank.MarketAnalysis</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name>B-Bank</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>B-Bank</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>B-Bank</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-\end{verbatim}
-\end{tiny}
-\end{minipage} &
-\begin{minipage}{0.475\textwidth}
-\begin{tiny}
-\begin{verbatim}
-  <VirtualMachineLabel>
-    <Name>AutoCorp</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>AutoCorp</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>AutoCorp</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  </SubjectLabels>
-  <ObjectLabels>
-  <ResourceLabel>
-    <Name>SystemManagement</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>SystemManagement</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name>__UNLABELED__</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>__UNLABELED__</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name>A-Bank</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name>A-Bank.SecurityUnderwriting</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank.SecurityUnderwriting</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name>A-Bank.MarketAnalysis</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank.MarketAnalysis</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name>B-Bank</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>B-Bank</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name>AutoCorp</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>AutoCorp</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  </ObjectLabels>
-</SecurityLabelTemplate>
-</SecurityPolicyDefinition>
-
-
-
-
-
-
-
-
-\end{verbatim}
-\end{tiny}
-\end{minipage}
-\end{tabular*}
-\caption{Example XML security policy file -- Part II: Label Definition.}
-\label{fig:acmxmlfileb}
-\end{figure}
-% DO NOT MODIFY WHITESPACE ABOVE, it balances the columns
-The \verb|SecurityLabelTemplate| (cf Figure~\ref{fig:acmxmlfileb}) defines
-the security labels that can be associated with domains and resources when
-this policy is active (use the \verb|xm labels type=any| command described in
-Section~\ref{subsection:acmexamplelabeldomains} to list all available labels).
-
-The domain labels include
-Chinese Wall types while resource labels do not include Chinese Wall types.
-The \verb|SubjectLabels| policy section defines the labels that can be
-assigned to domains. The VM label
-\verb|A-Bank.SecurityUnderwriting| in Figure~\ref{fig:acmxmlfileb})
-associates the domain that carries it with the workload STE type
-\verb|A-Bank.SecurityUnderwriting| and with the CHWALL types \verb|A-Bank|
-and \verb|A-Bank.SecurityUnderwriting|. The ezPolicy tool
-assumes that any department workload will inherit any conflict set that
-is specified for its organization, i.e., if \verb|B-Bank| is running, not
-only \verb|A-Bank| but also all its departmental workloads are prevented
-from running by this first run-time exclusion set. The separation of STE
-and CHWALL types in the label definition ensures that
-all departmental workloads are isolated from each other and from their generic
-organization workloads, while they are sharing CHWALL types to
-simplify the formulation of run-time exclusion sets.
-
-The \verb|bootstrap| attribute of the \verb|<SubjectLabels>| XML node
-in our example policy shown in Figure~\ref{fig:acmxmlfileb} names
-the label \verb|SystemManagement| as the label that Xen will assign
-to Domain-0 at boot time (if this policy is installed as boot policy). The
-label of Domain-0 can be persistently changed at run-time with the
-\verb|addlabel| command, which adds an overriding option to the grub.conf
-boot entry (cf Section~\ref{subsection:acmlabeldom0}).
-All user domains are assigned labels according to their domain configuration
-(see Section~\ref{subsection:acmexamplelabeldomains} for examples of
-how to label domains).
-
-The \verb|ObjectLabels| depicted in Figure~\ref{fig:acmxmlfileb} 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, Domain-0 is assigned the bootstrap label
-\verb|SystemManagement|, which includes all existing STE types.
-Therefore, Domain-0 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.
-Similarly, the STE and CHWALL types should be named according to the
-workloads they represent. While the XML representation of the label
-in the above example seems unnecessary flexible, labels in general
-must be able to include multiple types.
-
-We assume in the following example, that \verb|A-Bank.SecurityUnderwriting| and
-\verb|A-Bank.MarketAnalysis| workloads use virtual disks that are provided
-by a virtual I/O domain hosting a physical storage device and carrying
-the following label:
-
-\begin{scriptsize}
-\begin{verbatim}
-        <VirtualMachineLabel>
-          <Name>VIOServer</Name>
-          <SimpleTypeEnforcementTypes>
-              <Type>A-Bank</Type>
-              <Type>A-Bank.SecurityUnderwriting</Type>
-              <Type>A-Bank.MarketAnalysis</Type>
-              <Type>VIOServer</Type>
-          </SimpleTypeEnforcementTypes>
-          <ChineseWallTypes>
-              <Type>VIOServer</Type>
-          </ChineseWallTypes>
-        </VirtualMachineLabel>
-\end{verbatim}
-\end{scriptsize}
-
-This Virtual I/O domain (VIO) exports its virtualized disks by
-communicating to all domains labeled with the
-\verb|A-Bank.SecurityUnderwriting|, the \verb|A-Bank|, or the
-\verb|A-Bank.MarketAnalysis| label. This requires the
-VIO domain to carry those STE types. In addition, this label includes a
-new \verb|VIOServer| type that can be used to restrict direct access to the
-physical storage resource to the VIODomain.
-
-In this example, the confinement of  these A-Bank workloads depends on the
-VIO domain that must keep the data of those different workloads separate.
-The virtual disks are labeled as well to keep track of their assignments
-to workload types (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 \verb|A-Bank.SecurityUnderwriting|
-or \verb|A-Bank.MarketAnalysis| workloads.
-
-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 virtualized devices
-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{Managing sHype/Xen Security Policies at Run-time}
-\label{subsection:acmpolicymanagement}
-
-\subsubsection{Removing the sHype/Xen Security Policy}
-When resetting the policy, no labeled domains can be running.
-Please stop or shutdown all running labeled domains. Then you can reset
-the policy to the default policy using the \verb|resetpolicy| command:
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm getpolicy
-Supported security subsystems   : ACM
-Policy name           : mytest
-Policy type           : ACM
-Version of XML policy : 1.0
-Policy configuration  : loaded, activated for boot
-
-# xm resetpolicy
-Successfully reset the system's policy.
-
-# xm getpolicy
-Supported security subsystems   : ACM
-Policy name           : DEFAULT
-Policy type           : ACM
-Version of XML policy : 1.0
-Policy configuration  : loaded
-
-# xm resources
-file:/home/xen/dom_fc5/fedora.fc5.swap
-      type: INV_ACM
-    policy: mytest
-     label: A-Bank
-file:/home/xen/dom_fc5/fedora.fc5.img
-      type: INV_ACM
-    policy: mytest
-     label: A-Bank
-\end{verbatim}
-\end{scriptsize}
-
-As the \verb|xm resources| output shows, all resource labels have
-invalidated type information but their semantics remain associated
-with the resources so that they can later on either be relabeled
-with semantically equivalent labels or sanitized and reused
-(storage resources).
-
-At this point, the system is in the same initial state as after
-configuring XSM and sHype/ACM and rebooting the system without
-a specific policy. No user domains can run.
-
-\subsubsection{Changing to a Different sHype/Xen Security Policy}
-The easiest way to change to a different, unrelated policy is to reset the system
-policy and then set the new policy. Please consider that the existing
-domain and resource labels become invalid at this point. Please refer
-to the next section for an example of how to seamlessly update an
-active policy at run-time without invalidating labels.
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm resetpolicy
-Successfully reset the system's policy.
-
-# xm setpolicy ACM example.test
-Successfully set the new policy.
-Supported security subsystems   : ACM
-Policy name           : example.test
-Policy type           : ACM
-Version of XML policy : 1.0
-Policy configuration  : loaded, activated for boot
-
-# xm labels
-CocaCola
-PepsiCo
-SystemManagement
-VIO
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-Domain-0   0   873     1     r-----     56.3  ACM:example.test:SystemManagement
-
-# xm resetpolicy
-Successfully reset the system's policy.
-
-# xm getpolicy
-Supported security subsystems   : ACM
-Policy name           : DEFAULT
-Policy type           : ACM
-Version of XML policy : 1.0
-Policy configuration  : loaded
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-Domain-0   0   873     1     r-----     57.2  ACM:DEFAULT:SystemManagement
-
-# xm setpolicy ACM mytest
-Successfully set the new policy.
-Supported security subsystems   : ACM
-Policy name           : mytest
-Policy type           : ACM
-Version of XML policy : 1.0
-Policy configuration  : loaded, activated for boot
-
-# xm labels
-A-Bank
-A-Bank.MarketAnalysis
-A-Bank.SecurityUnderwriting
-AutoCorp
-B-Bank
-SystemManagement
-__UNLABELED__
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-Domain-0   0   873     1     r-----     58.0  ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-The described way of changing policies by resetting the existing
-policy is useful for testing different policies. For real deployment
-environments, a policy update as described in the following section
-is more appropriate and can be applied seamlessly at run-time while
-user domains are running.
-
-\subsubsection{Update an sHype/Xen Security Policy at Run-time}
-
-Once an ACM security policy is activated (loaded into the Xen
-hypervisor), the policy may be updated at run-time without the
-need to re-boot the system. The XML update-policy contains several
-additional information fields that are required to safely link the
-new policy contents to the old policy and ensure a consistent
-transformation of the system security state from the old to the
-new policy. Those additional fields are required for policies that
-are updating an existing policy at run-time.
-
-The major benefit of policy updates is the ability to add, delete,
-or rename workload types, labels, and conflict sets (run-time
-exclusion rules) to accommodate changes in the managed virtual
-environment without the need to reboot the Xen system. When a
-new policy renames labels of the current policy, the labels
-attached to resources and domains are automatically updated
-during a successful policy update.
-
-We have manually crafted an update policy for the \verb|mytest|
-security policy and stored it in the file mytest\_update-security\_policy.xml
-in the policies directory. We will discuss this policy in detail before
-using it to update a running sHype/Xen system. The following figures contain
-the whole contents of the update policy file.
-
-Figure~\ref{fig:acmupdateheader} shows the policy
-header of an update-policy and the new \verb|FromPolicy| XML
-node. For the policy update to succeed, the policy name and the
-policy version fields of the \verb|FromPolicy| XML node must
-exactly match those of the currently enforced policy. This
-ensures a controlled update path of the policy.
-
-\begin{figure}[htb]
-\begin{scriptsize}
-\begin{verbatim}
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Auto-generated by ezPolicy        -->
-<SecurityPolicyDefinition xmlns="http://www.ibm.com"
-xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-xsi:schemaLocation="http://www.ibm.com ../../security_policy.xsd ">
-    <PolicyHeader>
-        <PolicyName>mytest</PolicyName>
-        <Date>Tue Nov 27 21:53:45 2007</Date>
-        <Version>1.1</Version>
-        <FromPolicy>
-            <PolicyName>mytest</PolicyName>
-            <Version>1.0</Version>
-        </FromPolicy>
-    </PolicyHeader>
-\end{verbatim}
-\end{scriptsize}
-\caption{XML security policy update -- Part I: Updated Policy Header.}
-\label{fig:acmupdateheader}
-\end{figure}
-
-The version number of the new policy, which is shown in the
-node following the \verb|Date| node, must be a logical increment
-to the current policy's version. Therefore at least the minor
-number of the policy version must be incremented. This ensures
-that a policy update is applied only to exactly the policy for
-which this update was created and minimizes unforseen side-effects
- of policy updates.
-
-\paragraph{Types and Conflic Sets}
-The type names and the assignment of types to labels or conflict
-sets (run-time exclusion rules) can
-simply be changed consistently throughout the policy. Types,
-as opposed to labels, are not directly associated or referenced
-outside the policy so they do not need to carry their history
-in a ``From'' field. The figure below shows the update for the
-types and conflict sets. The \verb|__UNLABELED__| type is removed
-to disable support for running unlabeled domains. Additionally,
-we have renamed the two \verb|A-Bank| department types with
-abbreviated names \verb|A-Bank.SU| and \verb|A-Bank.MA|. You
-can also see how those type names are
-consistently changed within the conflict set definition.
-
-\begin{figure}[htb]
-\begin{scriptsize}
-\begin{verbatim}
-    <SimpleTypeEnforcement>
-        <SimpleTypeEnforcementTypes>
-            <Type>SystemManagement</Type>
-            <Type>A-Bank</Type>
-            <Type>A-Bank.SU</Type>
-            <Type>A-Bank.MA</Type>
-            <Type>B-Bank</Type>
-            <Type>AutoCorp</Type>
-        </SimpleTypeEnforcementTypes>
-    </SimpleTypeEnforcement>
-
-    <ChineseWall priority="PrimaryPolicyComponent">
-        <ChineseWallTypes>
-            <Type>SystemManagement</Type>
-            <Type>A-Bank</Type>
-            <Type>A-Bank.SU</Type>
-            <Type>A-Bank.MA</Type>
-            <Type>B-Bank</Type>
-            <Type>AutoCorp</Type>
-        </ChineseWallTypes>
-
-        <ConflictSets>
-            <Conflict name="RER">
-                <Type>A-Bank</Type>
-                <Type>B-Bank</Type>
-            </Conflict>
-            <Conflict name="RER">
-                <Type>A-Bank.MA</Type>
-                <Type>A-Bank.SU</Type>
-            </Conflict>
-       </ConflictSets>
-    </ChineseWall>
-\end{verbatim}
-\end{scriptsize}
-\caption{XML security policy update -- Part II: Updated Types and Conflict Sets.}
-\label{fig:acmupdatetypesnrules}
-\end{figure}
-
-In the same way, new types can be introduced and new conflict sets
-can be defined by simply adding the types or conflict sets to the
-update policy.
-
-\paragraph{Labels} Virtual machine and resource labels of an existing policy can be
-deleted through a policy update simply by omitting them in the
-update-policy. However, if a currently running virtual machine
-or a currently used resource is labeled with a label not stated
-in the update-policy, then the policy update is rejected. This
-ensures that a policy update leaves the system in a consistent
-security state.
-
-A policy update also enables the renaming of virtual machine and
-resource labels. Linking the old label name with the new label
-name is achieved through the \verb|from| attribute in the
-\verb|VirtualMachineLabel| or \verb|ResourceLabel| nodes in the
-update-policy. Figure~\ref{fig:acmupdatelabels} shown how subject
-and resource labels
-are updated from their old name \verb|A-Bank.SecurityUnterwriting|
-to their new name \verb|A-Bank.SU| using the \verb|from| attribute.
-
-\begin{figure}[htb]
-\begin{tabular*}{\textwidth}{@{\extracolsep{\fill}}l|l}
-\begin{minipage}{0.475\textwidth}
-\begin{tiny}
-\begin{verbatim}
-<SecurityLabelTemplate>
-  <SubjectLabels bootstrap="SystemManagement">
-  <VirtualMachineLabel>
-    <Name>SystemManagement</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>SystemManagement</Type>
-      <Type>A-Bank</Type>
-      <Type>A-Bank.SU</Type>
-      <Type>A-Bank.MA</Type>
-      <Type>B-Bank</Type>
-      <Type>AutoCorp</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>SystemManagement</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name>A-Bank-WL</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>SystemManagement</Type>
-      <Type>A-Bank</Type>
-      <Type>A-Bank.SU</Type>
-      <Type>A-Bank.MA</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>SystemManagement</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name>A-Bank</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>A-Bank</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name from="A-Bank.SecurityUnderwriting">
-            A-Bank.SU</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank.SU</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>A-Bank</Type>
-      <Type>A-Bank.SU</Type>
-    </ChineseWallTypes>
-   </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name from="A-Bank.MarketAnalysis">
-            A-Bank.MA</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank.MA</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>A-Bank</Type>
-      <Type>A-Bank.MA</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-\end{verbatim}
-\end{tiny}
-\end{minipage} &
-\begin{minipage}{0.475\textwidth}
-\begin{tiny}
-\begin{verbatim}
-  <VirtualMachineLabel>
-    <Name>B-Bank</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>B-Bank</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>B-Bank</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-  <VirtualMachineLabel>
-    <Name>AutoCorp</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>AutoCorp</Type>
-    </SimpleTypeEnforcementTypes>
-    <ChineseWallTypes>
-      <Type>AutoCorp</Type>
-    </ChineseWallTypes>
-  </VirtualMachineLabel>
-</SubjectLabels>
-
-<ObjectLabels>
-  <ResourceLabel>
-    <Name>SystemManagement</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>SystemManagement</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name>A-Bank</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name from="A-Bank.SecurityUnderwriting">
-            A-Bank.SU</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank.SU</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name from="A-Bank.MarketAnalysis">
-            A-Bank.MA</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>A-Bank.MA</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name>B-Bank</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>B-Bank</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  <ResourceLabel>
-    <Name>AutoCorp</Name>
-    <SimpleTypeEnforcementTypes>
-      <Type>AutoCorp</Type>
-    </SimpleTypeEnforcementTypes>
-  </ResourceLabel>
-  </ObjectLabels>
-</SecurityLabelTemplate>
-</SecurityPolicyDefinition>
-\end{verbatim}
-\end{tiny}
-\end{minipage}
-\end{tabular*}
-\caption{XML security policy update -- Part III: Updated Label Definition.}
-\label{fig:acmupdatelabels}
-\end{figure}
-% DO NOT MODIFY WHITESPACE ABOVE, it balances the columns
-
-The updated label definition also includes a new label \verb|A-Bank-WL|
-that includes all STE types related to A-Bank. Its CHWALL type
-is \verb|SystemManagement|. This indicates that this label is designed
-as Domain-0 label. A Xen system can be restricted to only run A-Bank
-related workloads by relabeling Domain-0 with the \verb|A-Bank-WL| label.
-
-We assume that the update-policy shown in
-Figures~\ref{fig:acmupdateheader}, \ref{fig:acmupdatetypesnrules}
-and \ref{fig:acmupdatelabels}
-is stored in the XML file mytest\_update-security\_policy.xml located
-in the ACM policy directory. See Section~\ref{subsection:acmnaming}
-for information about policy names and locations.
-
-The following \verb|xm setpolicy| command updates the active ACM
-security policy at run-time.
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm list --label
-Name      ID   Mem VCPUs    State  Time(s) Label
-domain1    2   128     1   -b----     0.6  ACM:mytest:A-Bank
-domain4    3   164     1   -b----     0.3  ACM:mytest:A-Bank.SecurityUnderwriting
-Domain-0   0   711     1   r-----    71.8  ACM:mytest:SystemManagement
-
-# xm resources
-file:/home/xen/dom_fc5/fedora.fc5.swap
-      type: ACM
-    policy: mytest
-    label:  A-Bank
-file:/home/xen/dom_fc5/fedora.fc5.img
-      type: ACM
-    policy: mytest
-    label:  A-Bank
-
-# xm setpolicy ACM mytest_update
-Successfully set the new policy.
-Supported security subsystems   : ACM
-Policy name           : mytest
-Policy type           : ACM
-Version of XML policy : 1.1
-Policy configuration  : loaded, activated for boot
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1    2   128     1     -b----      0.7  ACM:mytest:A-Bank
-domain4    3   164     1     -b----      0.3  ACM:mytest:A-Bank.SU
-Domain-0   0   711     1     r-----     72.8  ACM:mytest:SystemManagement
-
-# xm labels
-A-Bank
-A-Bank-WL
-A-Bank.MA
-A-Bank.SU
-AutoCorp
-B-Bank
-
-# xm resources
-file:/home/xen/dom_fc5/fedora.fc5.swap
-      type: ACM
-    policy: mytest
-     label: A-Bank
-file:/home/xen/dom_fc5/fedora.fc5.img
-      type: ACM
-    policy: mytest
-     label: A-Bank
-    \end{verbatim}
-\end{scriptsize}
-
-After successful completion of this command, \verb|xm list --label|
-shows that the labels of running domains changed to their new names.
-\verb|xm labels| shows that new labels \verb|A-Bank.SU| and \verb|A-Bank.AM|
-are now available in the policy. The resource labels remain valid after
-the successful update as \verb|xm resources| confirms.
-
-The \verb|setpolicy| command fails if the new policy is inconsistent
-with the current one or the policy is inconsistent internally (e.g., types
-are renamed in the type definition but not in the label definition part of
-the policy). In this case, the old policy remains active.
-
-After relabeling Domain-0 with the new \verb|A-Bank-WL| label, we can no
-longer run domains labeled \verb|B-Bank| or \verb|AutoCorp| since their
-STE types are not a subset of the new Domain-0 label.
-
-\begin{scriptsize}
-\begin{verbatim}
-# xm addlabel A-Bank-WL mgt Domain-0
-Successfully set the label of domain 'Domain-0' to 'A-Bank-WL'.
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1    2   128     1     -b----      0.8  ACM:mytest:A-Bank
-Domain-0   0   711     1     r-----     74.5  ACM:mytest:A-Bank-WL
-domain4    3   164     1     -b----      0.3  ACM:mytest:A-Bank.SU
-
-# xm getlabel dom domain3.xm
-policytype=ACM,policy=mytest,label=AutoCorp
-
-# xm create domain3.xm
-Using config file "./domain3.xm".
-Error: VM is not authorized to run.
-
-# xm addlabel SystemManagement mgt Domain-0
-Successfully set the label of domain 'Domain-0' to 'SystemManagement'.
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1    2   128     1     -b----      0.8  ACM:mytest:A-Bank
-domain4    3   164     1     -b----      0.3  ACM:mytest:A-Bank.SU
-Domain-0   0   709     1     r-----     76.4  ACM:mytest:SystemManagement
-
-# xm create domain3.xm
-Using config file "./domain3.xm".
-Started domain domain3
-
-# xm list --label
-Name      ID   Mem VCPUs      State   Time(s) Label
-domain1    2   128     1     -b----      0.8  ACM:mytest:A-Bank
-domain4    3   164     1     -b----      0.3  ACM:mytest:A-Bank.SU
-domain3    4   164     1     -b----      0.3  ACM:mytest:AutoCorp
-Domain-0   0   547     1     r-----     77.5  ACM:mytest:SystemManagement
-\end{verbatim}
-\end{scriptsize}
-
-In the same manner, you can add new labels to support new workloads and
-add, delete, or rename workload types (STE and/or CHWALL types) simply
-by changing the composition of labels. Another use case is to add new
-workload types to the current Domain-0 label to enable them to run.
-Conflict sets (run-time exclusion rules) can be simply omitted or added.
-The policy and label changes become active at once and new workloads
-can be run in protected mode without rebooting the Xen system.
-
-In all these cases, if any running user domain would--under the new policy--not
-be allowed to run or would not be allowed to access any of the resources
-it currently uses, then the policy update is rejected. In this case, you
-can stop domains that conflict with the new policy and update the policy
-afterwards. The old policy remains active until a policy update succeeds
-or Xen is re-booted into a new policy.
-
-\subsection{Tools For Creating sHype/Xen Security Policies}
-To create a security policy for Xen, you can use one of the following
-tools:
-\begin{itemize}
-\item \verb|ezPolicy| GUI tool -- start writing policies
-\item \verb|xensec_gen| tool -- refine policies created with \verb|ezPolicy|
-\item text or XML editor
-\end{itemize}
-
-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
-Subsection~\ref{subsection:acmexampleinstall}).
-
-\section{Current Limitations}
-\label{section:acmlimitations}
-
-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
-storage).
-
-On a single Xen system, information about the association of resources
-and security labels is stored in
-\verb|/var/lib/xend/security/policies/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
-stream.
-
-\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, e.g.,
-run-time exclusion rules (cf Section~\ref{subsection:acmexamplecreate})
-or limiting the system authorization (cf Section~\ref{subsection:acmlabeldom0}).
-
-
 \part{Reference}
 
 %% Chapter Build and Boot Options