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)
Reiner
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
\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 Domain0 (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 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
+missing.
+
+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
+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 provide access decisions. Workload types are represented by
+security labels that can be attached 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 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}
+\label{section:acmexample}
+
+What you are about to do consists of the following sequence:
+\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 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
+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: 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}
+
+\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 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:
+
+\begin{verbatim}
+ (3) # xensec_ezpolicy
+\end{verbatim}
+
+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:
+\begin{enumerate}
+\item defining workloads
+\item defining run-time conflicts
+\item translating the workload definition into a 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. 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
+Figure~\ref{fig:acmezpolicy}.
+
+\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.
+
+\begin{figure}[htb]
+\centering
+\includegraphics[width=13cm]{figs/acm_ezpolicy.eps}
+\caption{Final layout including workload definition and Run-time Exclusion
rules.}
+\label{fig:acmezpolicy}
+\end{figure}
+
+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
+policies.
+
+\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 (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:
+
+\begin{verbatim}
+ (4) # xm makepolicy example.chwall_ste.test-wld
+\end{verbatim}
+
+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:
+
+\begin{verbatim}
+ (5) # xm cfgbootpolicy example.chwall_ste.test-wld
+\end{verbatim}
+
+\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
+directory:
+
+\begin{scriptsize}
+\begin{verbatim}
+ # cp /etc/xen/acm-security/policies/example/chwall_ste/test-wld.bin \
+ /boot/example.chwall_ste.test-wld.bin
+\end{verbatim}
+\end{scriptsize}
+
+Second, 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 (2.6.16.13)
+ root (hd0,0)
+ kernel /xen.gz dom0_mem=2000000 console=vga
+ module /vmlinuz-2.6.16.13-xen ro root=/dev/hda3
+ module /initrd-2.6.16.13-xen.img
+ module /example.chwall_ste.test-wld.bin
+\end{verbatim}
+\end{scriptsize}
+
+Now reboot into this Xen boot entry to activate the policy and the
+security-enabled Xen hypervisor.
+
+\begin{verbatim}
+ (6) # reboot
+\end{verbatim}
+
+After reboot, check if security is enabled:
+
+\begin{scriptsize}
+\begin{verbatim}
+ # xm list --label
+ Name ID Mem(MiB) VCPUs State Time(s) Label
+ Domain-0 0 1949 4 r----- 163.9 SystemManagement
+\end{verbatim}
+\end{scriptsize}
+
+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}
+\label{subsection:acmexamplelabeldomains}
+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|:
+
+\begin{scriptsize}
+\begin{verbatim}
+ # cat domain1.xm
+ kernel = "/boot/vmlinuz-2.6.16.13-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.swap,sda2,w']
+ root = "/dev/sda1 ro"
+\end{verbatim}
+\end{scriptsize}
+
+If you try to start domain1, you will get the following error:
+
+\begin{scriptsize}
+\begin{verbatim}
+ # xm create domain1.xm
+ Using config file "domain1.xm".
+ domain1: DENIED
+ --> Domain not labeled
+ Checking resources: (skipped)
+ Security configuration prevents domain from starting
+\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. The following command prints all domain
+labels available in the active policy:
+
+\begin{scriptsize}
+\begin{verbatim}
+ # xm labels type=dom
+ Avis
+ CocaCola
+ CocaCola.Extranet
+ CocaCola.HumanResources
+ CocaCola.Intranet
+ CocaCola.Payroll
+ Hertz
+ PepsiCo
+ PepsiCo.Extranet
+ PepsiCo.Intranet
+ SystemManagement
+\end{verbatim}
+\end{scriptsize}
+
+Now label domain1 with the CocaCola label and another domain2 with the
+PepsiCo.Extranet label. Please refer to the xm man page for further
+information.
+
+\begin{verbatim}
+ (7) # xm addlabel CocaCola dom domain1.xm
+ # xm addlabel PepsiCo.Extranet 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".
+ 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
+\end{verbatim}
+\end{scriptsize}
+
+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
+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 CocaCola resource label to the domain1
+image file representing \verb|/dev/sda1| and to its swap file:
+
+\begin{verbatim}
+ (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
+\end{verbatim}
+
+Starting \verb|domain1| now will succeed:
+
+\begin{scriptsize}
+\begin{verbatim}
+ # 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
+\end{verbatim}
+\end{scriptsize}
+
+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.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
+\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|xm rmlabel| and \verb|xm addlabel|
+respectively. Please see Section~\ref{section:acmlimitations} for
+further details.
+
+\begin{verbatim}
+ (9) Label the resources of domain2 as PepsiCo.Extranet
+ Do not try to start this domain yet
+\end{verbatim}
+
+\subsection{Testing The Xen Workload Protection}
+\label{subsection:acmexampletest}
+We are about to demonstrate how the workload protection works by
+verifying:
+\begin{itemize}
+\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
+\end{itemize}
+
+\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
+exclusions).
+
+\begin{scriptsize}
+\begin{verbatim}
+# 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
+\end{verbatim}
+\end{scriptsize}
+
+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.
+
+\begin{scriptsize}
+\begin{verbatim}
+# xm rmlabel res file:/home/xen/dom_fc5/fedora.swap
+# xm addlabel Avis res file:/home/xen/dom_fc5/fedora.swap
+# xm resources
+file:/home/xen/dom_fc5/fedora.swap
+ policy: example.chwall_ste.test-wld
+ label: Avis
+file:/home/xen/dom_fc5/fedora.fc5.img
+ 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
+\end{verbatim}
+\end{scriptsize}
+
+\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}
+\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 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:
+\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" 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>
+08
+09 <SimpleTypeEnforcement>
+10 <SimpleTypeEnforcementTypes>
+11 <Type>SystemManagement</Type>
+12 <Type>PepsiCo</Type>
+13 <Type>CocaCola</Type>
+14 </SimpleTypeEnforcementTypes>
+15 </SimpleTypeEnforcement>
+16
+17 <ChineseWall priority="PrimaryPolicyComponent">
+18 <ChineseWallTypes>
+19 <Type>SystemManagement</Type>
+20 <Type>PepsiCo</Type>
+21 <Type>CocaCola</Type>
+22 </ChineseWallTypes>
+23
+24 <ConflictSets>
+25 <Conflict name="RER1">
+26 <Type>CocaCola</Type>
+27 <Type>PepsiCo</Type>
+28 </Conflict>
+29 </ConflictSets>
+30 </ChineseWall>
+31
+\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-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
+approach.
+
+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:
+
+\begin{scriptsize}
+\begin{verbatim}
+ <Conflict name="RER1">
+ <Type>CocaCola</Type>
+ <Type>PepsiCo</Type>
+ </Conflict>
+\end{verbatim}
+\end{scriptsize}
+
+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:
+
+\begin{itemize}
+\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.
+\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}
+\begin{scriptsize}
+\begin{verbatim}
+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>
+45
+46 <VirtualMachineLabel>
+47 <Name>PepsiCo</Name>
+48 <SimpleTypeEnforcementTypes>
+49 <Type>PepsiCo</Type>
+50 </SimpleTypeEnforcementTypes>
+51 <ChineseWallTypes>
+52 <Type>PepsiCo</Type>
+53 </ChineseWallTypes>
+54 </VirtualMachineLabel>
+55
+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>
+66
+67 <ObjectLabels>
+68 <ResourceLabel>
+69 <Name>SystemManagement</Name>
+70 <SimpleTypeEnforcementTypes>
+71 <Type>SystemManagement</Type>
+72 </SimpleTypeEnforcementTypes>
+73 </ResourceLabel>
+74
+75 <ResourceLabel>
+76 <Name>PepsiCo</Name>
+77 <SimpleTypeEnforcementTypes>
+78 <Type>PepsiCo</Type>
+79 </SimpleTypeEnforcementTypes>
+80 </ResourceLabel>
+81
+82 <ResourceLabel>
+83 <Name>CocaCola</Name>
+84 <SimpleTypeEnforcementTypes>
+85 <Type>CocaCola</Type>
+86 </SimpleTypeEnforcementTypes>
+87 </ResourceLabel>
+88 </ObjectLabels>
+89 </SecurityLabelTemplate>
+90 </SecurityPolicyDefinition>
+\end{verbatim}
+\end{scriptsize}
+\caption{Example XML security policy file -- Part II: Label Definition.}
+\label{fig:acmxmlfileb}
+\end{figure}
+
+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:
+
+\begin{scriptsize}
+\begin{verbatim}
+ <VirtualMachineLabel>
+ <Name>VIO</Name>
+ <SimpleTypeEnforcementTypes>
+ <Type>CocaCola</Type>
+ <Type>PepsiCo</Type>
+ </SimpleTypeEnforcementTypes>
+ <ChineseWallTypes>
+ <Type>VIOServer</Type>
+ </ChineseWallTypes>
+ </VirtualMachineLabel>
+\end{verbatim}
+\end{scriptsize}
+
+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
+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 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
+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|/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
+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
+(cf. run-time exclusion rules).
+
\part{Reference}
%% Chapter Build and Boot Options
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home