# HG changeset patch
# User kfraser@xxxxxxxxxxxxxxxxxxxxx
# Node ID 16f1f8ac89024de4a2d5399411d703e281f40c49
# Parent 6677b97612a2356bba8717c111dc062e8bfe2ad5
[ACM] Documentation cleanup.
This patch eliminates redundant security tools information that was
integrated into the Xen user guide and the xm man page.
Signed-off by: Reiner Sailer <sailer@xxxxxxxxxx>
---
tools/security/example.txt | 376 -----------------------------------------
tools/security/install.txt | 87 ---------
tools/security/policy.txt | 163 ++---------------
tools/security/policytools.txt | 148 ++++++++++++++++
tools/security/readme.txt | 31 +--
5 files changed, 184 insertions(+), 621 deletions(-)
diff -r 6677b97612a2 -r 16f1f8ac8902 tools/security/policy.txt
--- a/tools/security/policy.txt Fri Oct 20 10:46:37 2006 +0100
+++ b/tools/security/policy.txt Fri Oct 20 10:48:34 2006 +0100
@@ -1,130 +1,12 @@
##
-# policy.txt <description to the Xen access control architecture>
+# policy.txt <description to the sHype/Xen access control architecture>
#
# Author:
-# Reiner Sailer 08/15/2005 <sailer@xxxxxxxxxxxxxx>
-#
-#
-# This file gives an overview of the security policies currently
-# provided and also gives some reasoning about how to assign
-# labels to domains.
+# Reiner Sailer 08/30/2006 <sailer@xxxxxxxxxxxxxx>
+#
+#
+# This file gives an overview of the example security policies.
##
-
-Xen access control policies
-
-
-General explanation of supported security policies:
-=====================================================
-
-We have implemented the mandatory access control architecture of our
-hypervisor security architecture (sHype) for the Xen hypervisor. It
-controls communication (in Xen: event channels, grant tables) between
-Virtual Machines (from here on called domains) and through this the
-virtual block devices, networking, and shared memory are implemented
-on top of these communication means. While we have implemented the
-described policies and access control architecture for other
-hypervisor systems, we will describe below specifically its
-implementation and use in the Xen hypervisor. The policy enforcement
-is called mandatory regarding user domains since the policy it is
-given by the security administration and enforced independently of the
-user domains by the Xen hypervisor in cooperation with the domain
-management.
-
-The access control architecture consists of three parts:
-
-i) The access control policy determines the "command set" of the ACM
-and the hooks with which they can be configured to constrain the
-sharing of virtual resources. The current access control architecture
-implemented for Xen supports two policies: Chinese Wall and Simple
-Type Enforcement, which we describe in turn below.
-
-
-ii) The actually enforced policy instantiation uses the policy
-language (i) to configure the Xen access control in a way that suits
-the specific application (home desktop environment, company desktop,
-Web server system, etc.). We have defined an exemplary policy
-instantiation for Chinese Wall (chwall policy) and Simple Type
-Enforcement (ste policy) for a desktop system. We offer these policies
-in combination since they are controlling orthogonal events.
-
-
-iii) The access control module (ACM) and related hooks are part of the
-core hypervisor and their controls cannot be bypassed by domains. The
-ACM and hooks are the active security components. We refer to
-publications that describe how access control is enforced in the Xen
-hypervisor using the ACM (access decision) and the hooks (decision
-enforcement) inserted into the setup of event channels and grant
-tables, and into domain operations (create, destroy, save, restore,
-migrate). These controls decide based on the active policy
-configuration (see i. and ii.) if the operation proceeds of if the
-operation is aborted (denied).
-
-In general, security policy instantiations in the Xen access control
-framework are defined by XML policy files. Each security policy has
-exactly one file including all the information the hypervisor needs to
-enforce the policy.
-
-The name of a policy is unique and consists of a colon-separated list
-of names, which can be translated into the location (subtree) where
-this policy must be located. The last part of the name is the file
-name pre-fix for the policy xml file. The preceding name parts are
-translated into the local path relative to the global policy root
-(/etc/xen/acm-security/policies) pointing to the policy xml file. For
-example: example.chwall_ste.client_v1 denotes the policy file
-example/chwall_ste/client_v1-security_policy.xml relative to the
-global policy root directory.
-
-Every security policy has its own sub-directory under the global
-policy root directory /etc/xen/acm-security/policies, which is
-installed during the Xen installation or can be manually installed
-(when switching from a "security disabled" Xen to a "security enabled"
-Xen AFTER configuring security, see install.txt) by the command
-sequence:
-
- cd "Xen-root"/tools/security/policies; make install
-
-We will describe those files for our example policy (Chinese Wall and
-Simple Type Enforcement) in more detail as we go along. Eventually, we
-will move towards a system installation where the policies will reside
-under /etc.
-
-
-CHINESE WALL
-============
-
-The Chinese Wall policy enables the user to define "which workloads
-(domain payloads) cannot run on a single physical system at the same
-time". Why would we want to prevent workloads from running at the same
-time on the same system? This supports requirements that can (but
-don't have to) be rooted in the measure of trust into the isolation of
-different domains that share the same hardware. Since the access
-control architecture aims at high performance and non-intrusive
-implementation, it currently does not address covert (timing) channels
-and aims at medium assurance. Users can apply the Chinese Wall policy
-to guarantee an air-gap between very sensitive payloads both regarding
-covert information channels and regarding resource starvation.
-
-To enable the CW control, each domain is labeled with a set of Chinese
-Wall types and CW Conflict Sets are defined which include those CW
-types that cannot run simultaneously on the same hardware. This
-interpretation of conflict sets is the only policy rule for the Chines
-Wall policy.
-
-This is enforced by controlling the start of domains according to
-their assigned CW worload types. Domains with Chinese Wall types that
-appear in a common conflict set are running mutually exclusive on a
-platform, i.e., once a domain with one of the cw-types of a conflict
-set is running, no domain with another cw-type of the same conflict
-set can start until the first domain is destroyed, paused, or migrated
-away from the physical system (this assumes that such a partition can
-no longer be observed). The idea is to assign cw-types according to
-the type of payload that a domain runs and to use the Chinese Wall
-policy to ensure that payload types can be differentiated by the
-hypervisor and can be prevented from being executed on the same system
-at the same time. Using the flexible CW policy maintains system
-consolidation and workload-balancing while introducing guaranteed
-constraints where necessary.
-
Example of a Chinese Wall Policy Instantiation
----------------------------------------------
@@ -233,13 +115,12 @@ with all domains during their setup, and
with all domains during their setup, and intercepts all communication
between domains. Consequently, Dom0 needs to be assigned all types
used and must be completely trusted to maintain the separation of
-informatio ncoming from domains with different STE types. Thus a
+information coming from domains with different STE types. Thus a
refactoring of Dom0 is recommended for stronger confinement
guarantees.
Domain --> RESOURCES Access
'''''''''''''''''''''''''''
-(current work)
We define for each resource that we want to distinguish a separate STE
type. Each STE type is assigned to the respective resource and to
@@ -266,8 +147,7 @@ maximum security benefit from sHype.
Example of a Simple Type Enforcement Policy Instantiation
---------------------------------------------------------
-
-We define the following types:
+The example policies define the following types:
* ste_SystemManagement identifies workloads (and domains that runs
them) that must share information to accomplish the management of the
@@ -384,19 +264,18 @@ co-operatively enforce the policy. In th
co-operatively enforce the policy. In the storage domain example, we
have three components that co-operate:
-1. The ACM module inside the hypervisor enforces: communication between
-user domains and the storage domain (only domains including types
-ste_PersonalFinances or ste_InternetInsecure can communicate with the
-storage domain and request access to logical resource). This confines
-the sharing to the types assigned to the storage domain.
-
-2. The domain management will enforce (work in progress): assignment of
-real resources (hda) to domains (storage domain) that share a
-type with the resource.
-
-3. If the storage domain serves multiple STE types (as in our example),
-it enforces (work in progress): that domains can access (mount)
-logical resources only if they share an STE type with the respective
+1. The ACM module inside the hypervisor enforces: communication
+between user domains and the storage domain (only domains including
+types ste_PersonalFinances or ste_InternetInsecure can communicate
+with the storage domain and request access to logical resource). This
+confines the sharing to the types assigned to the storage domain.
+
+2. The domain management enforces: assignment of real resources (hda)
+to domains (storage domain) that share a type with the resource.
+
+3. If the storage domain serves multiple STE types (as in our
+example), it enforces: that domains can access (mount) logical
+resources only if they share an STE type with the respective
resource. In our example, domains with the STE type
ste_PersonalFinances can request access (mount) to logical resource
hda1 from the storage domain.
@@ -406,8 +285,8 @@ drive hda for serving logical disk parti
drive hda for serving logical disk partitions exclusively to
dom_HomeBanking and dom_Fun.
-Similary, network domains can confine access to the network or
-network communication between user domains.
+Similary, network domains can confine access to the network or network
+communication between user domains.
As a result, device domains (e.g., storage domain, network domain)
must be simple and small to ensure their correct co-operation in the
diff -r 6677b97612a2 -r 16f1f8ac8902 tools/security/readme.txt
--- a/tools/security/readme.txt Fri Oct 20 10:46:37 2006 +0100
+++ b/tools/security/readme.txt Fri Oct 20 10:48:34 2006 +0100
@@ -1,34 +1,33 @@
##
-# readme.txt <description to the xen access control architecture>
+# readme.txt <description to the sHype/Xen access control architecture>
#
# Author:
-# Reiner Sailer 08/15/2005 <sailer@xxxxxxxxxxxxxx>
+# Reiner Sailer 08/30/2006 <sailer@xxxxxxxxxxxxxx>
#
#
# This file is a toc for information regarding
# the access control policy and tools in Xen.
##
-1. 'xm' man page
+1. Xen User Guide
+
+ describes how to configure, install, and deploy the sHype Access
+ Control Module in Xen. See chapter "sHype/Xen Access Control".
+
+2. 'xm' man page
describes the commands related to Xen management, including the
commands to manage security policies and labels. Read the access
- control subcommand section of the xm manual first. If it is not
- built by default, check install.txt.
+ control subcommand section of the xm manual first.
-2. policy.txt:
+3. policy.txt
- describes the general reasoning and examples for access
- control policies in Xen
+ describes examples for access control policies in Xen. First read
+ the policy description in the Xen User Guide.
-3. install.txt
+4. policytools.txt
- describes the activation of the access control framework
- in Xen
-
-4. example.txt
-
- describes the available tools for managing security policies
- in Xen and the tools to label domains
+ describes the available tools for creating and managing security
+ policies in Xen.
diff -r 6677b97612a2 -r 16f1f8ac8902 tools/security/policytools.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/security/policytools.txt Fri Oct 20 10:48:34 2006 +0100
@@ -0,0 +1,148 @@
+##
+# policytools.txt
+# <description to the sHype/Xen policy management tools>
+#
+# Author:
+# Reiner Sailer 08/31/2006 <sailer@xxxxxxxxxxxxxx>
+#
+#
+##
+
+This file describes the Xen-tools to create and maintain security
+policies for the sHype/Xen access control module.
+
+A security policy (e.g. "example.chwall_ste.test") is defined in
+XML. Read in the user manual about the naming of policies. The policy
+name is used by the Xen management tools to identify existing
+policies. Creating the security policy means creating a policy
+description in XML:
+/etc/xen/acm-security/policies/example/chwall_ste/test-security_policy.xml.
+
+The policy XML description must follow the XML schema definition in
+/etc/xen/acm-security/policies/security_policy.xsd. The policy tools
+are written against this schema; they will create and refine policies
+that conform to this scheme.
+
+Two tools are provided to help creating security policies:
+
+
+1. xensec_ezpolicy: The starting point for writing security policies.
+===================
+
+This wxPython-based GUI tool is meant to create very quickly a
+starting point for a workload protection security policy. Please start
+the tool (xensec_ezpolicy) and press <CTRL-h> for usage explanations.
+The Xen User guide explains its usage at an example in chapter
+"sHype/Xen Access Control".
+
+The output of the tool is a security policy that is fully operable. It
+is sufficient to create policies that demonstrate how sHype/ACM works.
+
+However, it defines only a basic set of security labels assuming that
+Domain0 hosts and virtualizes all hardware (storage etc.). Use
+xensec_gen to refine this policy and tailor it to your requirements.
+
+
+2. xensec_gen: The tool to refine a basic security policy:
+==============
+
+The xensec_gen utility starts a web-server that can be used to
+generate the XML policy files needed to create or maintain a
+policy. It can be pre-loaded with a policy file created by
+xensec_ezpolicy.
+
+By default, xensec_gen runs as a daemon and listens on port 7777 for
+HTTP requests. The xensec_gen command supports command line options
+to change the listen port, run in the foreground, and a few others.
+Type 'xensec_gen -h' to see the full list of options available.
+
+Once the xensec_gen utility is running, point a browser at the host
+and port on which the utility is running (e.g. http://localhost:7777).
+You will be presented with a web page that allows you to create or
+modify the XML policy file:
+
+ - The Security Policy types section allows you to create or modify
+the policy types and conflict set definitions
+
+ - The Security Policy Labeling section allows you to create or
+modify label definitions
+
+The policy generation tool allows you to modify an existing policy
+definition or create a new policy definition file. To modify an
+existing policy definition, enter the full path to the existing file
+(the "Browse" button can be used to aid in this) in the Policy File
+entry field. To create a new policy definition file leave the Policy
+File entry field blank. At this point click the "Create" button to
+begin modifying or creating your policy definition.
+
+ Security Policy Types Section
+ -----------------------------
+
+You will then be presented with a web page. The upper part of it will
+allow you to create either Simple Type Enforcement types or Chinese
+Wall types or both, as well as Chinese Wall conflict sets.
+
+As an example, to add a Simple Type Enforcement type:
+
+- Enter the name of a new type under the Simple Type Enforcement Types
+section in the entry field above the "New" button.
+
+- Click the "New" button and the type will be added to the list of
+defined Simple Type Enforcement types.
+
+To remove a Simple Type Enforcement type:
+
+- Click on the type to be removed in the list of defined Simple Type
+Enforcement types.
+
+- Click the "Delete" button to remove the type.
+
+Follow the same process to add Chinese Wall types. The Chinese Wall
+Conflict Set allows you to add Chinese Wall types from the list of
+defined Chinese Wall types.
+
+
+ Security Policy Labels:
+ -------------------------
+
+The security policy label section of the web page allows you to create
+labels for classes of virtual machines and resources. The input
+policy type definitions on the upper part of the web page will provide
+the available types (Simple Type Enforcement and/or Chinese Wall) that
+can be assigned to a virtual machine class. Resource classes only
+include simple type enforcement types; the Chinese Wall policy does
+apply only to virtual machines.
+
+As an example, to add a Virtual Machine class (the name entered will
+become the label that will be used to identify the class):
+
+- Enter the name of a new class under the Virtual Machine Classes
+section in the entry field above the "New" button.
+
+- Click the "New" button and the class will be added to the table of
+defined Virtual Machine classes.
+
+To remove a Virtual Machine class:
+
+- Click the "Delete" link associated with the class in the table of
+Virtual Machine classes.
+
+Once you have defined one or more Virtual Machine classes, you will
+be able to add any of the defined Simple Type Enforcement types or
+Chinese Wall types to a particular Virtual Machine.
+
+If you create a new policy, you must also define which Virtual Machine
+class is to be associated with the bootstrap domain (or Dom0 domain).
+By default, the first Virtual Machine class created will be associated
+as the bootstrap domain.
+
+To save your policy definition file, click on the "Generate XML"
+button on the top of the page. This will present you with a dialog
+box to save the generated XML file on your system. The default name
+will be security_policy.xml which you should change to follow the
+policy file naming conventions based on the policy name that you
+choose to use.
+
+To get a feel for the tool, you could use one of the example policy
+definitions files from /etc/xen/acm-security/policies/example as
+input or a policy created by the xensec_ezpolicy tool.
diff -r 6677b97612a2 -r 16f1f8ac8902 tools/security/example.txt
--- a/tools/security/example.txt Fri Oct 20 10:46:37 2006 +0100
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,376 +0,0 @@
-##
-# example.txt <description to the xen access control architecture>
-#
-# Author:
-# Reiner Sailer 08/15/2005 <sailer@xxxxxxxxxxxxxx>
-# 04/07/2006 update to using labels instead of ssidref
-#
-#
-# This file introduces into the tools to manage policies
-# and to label domains and resources.
-##
-
-We will show how to install and use the example one of the client_v1
-policies. Other policies work similarly. Feedback welcome!
-
-
-
-1. Using xm tools to translate example.chwall_ste.client_v1 policy:
-===================================================================
-
-#xm makepolicy example.chwall_ste.client_v1
-
-By default, the tool looks in directory /etc/xen/acm-security/policies
-for a directory that matches the policy name
-(here:example/chwall_ste/client_v1-security_policy.xml) to find the
-policy files. The '-d' option can be used to override the default
-/etc/xen/acm-security/policies policy-root directory.
-
-The default policy directory structure under /etc/xen/acm-security (and
-the Xen security tool build directory - tools/security) looks like:
-
-policies
-|-- security_policy.xsd
-|-- example
- |-- chwall
- | |-- client_v1-security_policy.xml
- |
- |-- chwall_ste
- | |-- client_v1-security_policy.xml
- |
- |-- ste
- |-- client_v1-security_policy.xml
-
-The security_policy.xsd file contains the schema against which the
-policy files must validate during translation.
-
-The policy files, ending in -security_policy.xml, define the policies,
-the types known to the policies, and the label definitions that group
-types together and make them easier to use for users.
-
-After executing the above 'xm makepolicy' command, you will find 2 new
-files in the /etc/xen/acm-security/policies/example/chwall_ste
-sub-directory:
-
- client_v1.map ... this file includes the mapping
- of names from the xml files into their binary code representation.
-
- client_v1.bin ... this is the binary policy file, the result of
- parsing the xml files and using the mapping to create a binary
- version that can be loaded into the hypervisor.
-
-
-
-2. Loading and activating the policy:
-=====================================
-
-We assume that xen is already configured for security;
-please refer to install.txt for instructions.
-
-To activate the policy from the command line:
-
-# xm loadpolicy example.chwall_ste.client_v1
-
-See install.txt for how to install a policy at boot time. This the
-recommended default. You can only load a policy if the currently
-enforced policy is "DEFAULT", a minimal startup policy, or if the
-currently enforced policy has the same name as the new one. Support
-for dynamic policy changes at run-time are a current working item.
-
-
-3. Labeling domains:
-====================
-
-a) Labeling Domain0:
-
-The chwall_ste-security_label_template.xml file includes an attribute
-"bootstrap", which is set to the label name that will be assigned to
-Dom0 (this label will be mapped to ssidref 1/1, the default for Dom0).
-
-b) Labeling User Domains (domains started from dom0 using xm commands):
-
-We distinguish two kinds of labels: a) VM labels (for domains) and RES
-Labels (for resources). We focus here on VM labels. Resource labels
-will be supported later.
-
-To list all available domain labels of a policy, use:
- #xm labels example.chwall_ste.client_v1
-
-To list all available labels including resource labels (their support
-is current work), use:
-
- #xm labels example.chwall_ste.client_v1 type=any
-
-The policy parameter is optional. The currently enforced hypervisor
-policy is used by default.
-
-If you would like to assign the dom_HomeBanking label to one of your user
domains,
-look at the hypothetical domain configuration contained in
/etc/xen/homebanking.xm:
-
- #------FOR HOME/ONLINE BANKING---------
- kernel = "/boot/vmlinuz-2.6.16-xen"
- ramdisk="/boot/U1_ramdisk.img"
- memory = 164
- name = "homebanking"
- vif=['']
- dhcp = "dhcp"
- #-------------------------
-
-Now we label this domain (policy name is optional, see above):
-
- # xm addlabel homebanking.xm dom_HomeBanking example.chwall_ste.client_v1
-
-The domain configuration should look now like:
-
- # cat homebanking.xm
- #------FOR HOME/ONLINE BANKING---------
- kernel = "/boot/vmlinuz-2.6.16-xen"
- ramdisk="/boot/U1_ramdisk.img"
- memory = 164
- name = "homebanking"
- vif=['']
- dhcp = "dhcp"
- access_control = ['policy=example.chwall_ste.client_v1,
label=dom_HomeBanking']
-
-You can see the access_control line that was added to the
-configuration. This label will be translated into a local ssidref when
-a domain is created or resumed (also after migration and
-live-migration). The ssidref is a local security reference that is
-used inside the hypervisor instead of the security label for
-efficiency reasons. Since the same label can be mapped onto different
-ssidrefs in different policy translations (e.g., if the position of
-the label definition is changed in the policy file) or on different
-systems, the ssidref is re-calculated from the label each time a
-domain is instantiated or re-instantiated.
-
-Currently, the labels are not held in the hypervisor but only in
-.map files in the /etc/xen/acm-security/policies subdirectories. Only
-ssidrefs are known inside the hypervisr. This of course can change in
-the future.
-
-
-4. Starting a labeled domain
-============================
-
-Now, start the domain:
-
- #xm create homebanking.xm
- Using config file "homebanking.xm".
- Started domain fun
-
-
-[root@941e-4 VMconfigs]# xm list --label
-
-Name ID Mem(MiB) VCPUs State Time(s) Label
-fun 1 64 1 -b---- 5.9 dom_HomeBanking
-Domain-0 0 1954 1 r----- 1321.4 dom_SystemManagement
-
-
-
-If you label another domain configuration as dom_Fun and if
-you try to start it afterwards, this create will fail.
-
-Why? -- Because the running 'homebanking' domain has the chinese
-wall type "cw_Sensitive". The new domain 'fun' has the chinese wall
-label "cw_Distrusted". These domains are not allowed to run simultaneously
-on the same system because of the defined conflict set
-
- <conflictset name="Protection1">
- <type>cw_Sensitive</type>
- <type>cw_Distrusted</type>
- </conflictset>
-
-(in client_v1-security_policy.xml), which says that only one of the
-types cw_Sensitive and cw_Distrusted can run at a time.
-
-If you save or shutdown the 'homebanking' domain, you will be able to
-start the 'fun' domain. You can look into the Xen log to see if a
-domain was denied to start because of the access control framework
-with the command 'xm dmesg'.
-
-It is important (and usually non-trivial) to define the labels in a
-way that the semantics of the labels are enforced and supported by the
-types and the conflict sets. Usually, a workload abstraction seems
-helpful on the hypervisor level.
-
-Note: While the chinese wall policy enforcement is complete, the type
-enforcement is currently enforced inside the Xen hypervisor
-only. Therefore, only point-to-point sharing with regard to the type
-enforcement is currently controlled. Enforcing the STE policy while
-sharing virtual resources is ongoing work and assumed to be complete
-by year end as well as enforcing the STE policy for network traffic
-routed through dom0.
-
-
-5. Adding your own policies
-===========================
-
-Writing your own policy (e.g. "mypolicy.chwall.test") requires the policy
-definition (types etc.) and the label definitions. Any policy name
-must have chwall, ste, or chwall_ste in its name. This is used by the
-configuration tool to identify existing binary policy entries in the
-boot configuration file (menu.lst, grub.con). This part should, of
-course, be consistent with policy type that is defined.
-
-First, you create
-/etc/xen/acm-security/policies/mypolicy/chwall/test-security_policy.xml.
-
-You need to keep to the schema as defined in
-/etc/xen/acm-security/security_policy.xsd since the translation tools
-are written against this schema.
-
-You can hand-edit the xml files to create your policy or you can use the
-xensec_gen utility.
-
-
-6. Generating policy files using xensec_gen:
-============================================
-
-The xensec_gen utility starts a web-server that can be used to generate the
-XML policy files needed to create a policy.
-
-By default, xensec_gen runs as a daemon and listens on port 7777 for HTTP
-requests. The xensec_gen command supports command line options to change the
-listen port, run in the foreground, and a few others. Type 'xensec_gen -h'
-to see the full list of options available.
-
-Once the xensec_gen utility is running, point a browser at the host and port
-on which the utility is running (e.g. http://localhost:7777/). You will be
-presented with a web page that allows you to create or modify the XML policy
-file:
-
- - The Security Policy types section allows you to create or modify
- the policy types and conflict set definitions
-
- - The Security Policy Labeling section allows you to create or modify a
- label definitions
-
-The policy generation tool allows you to modify an existing policy
-definition or create a new policy definition file. To modify an
-existing policy definition, enter the full path to the existing file
-(the "Browse" button can be used to aid in this) in the Policy File
-entry field. To create a new policy definition file leave the Policy
-File entry field blank. At this point click the "Create" button to
-begin modifying or creating your policy definition.
-
- Security Policy Types Section
- -----------------------------
-
-You will then be presented with a web page. The upper part of it will
-allow you to create either Simple Type Enforcement types or Chinese
-Wall types or both, as well as Chinese Wall conflict type sets.
-
- As an example:
- - To add a Simple Type Enforcement type:
- - Enter the name of a new type under the Simple Type Enforcement Types
- section in the entry field above the "New" button.
- - Click the "New" button and the type will be added to the list of
defined
- Simple Type Enforcement types.
- - To remove a Simple Type Enforcement type:
- - Click on the type to be removed in the list of defined Simple Type
- Enforcement types.
- - Click the "Delete" button to remove the type.
-
- Follow the same process to add Chinese Wall types. If you define Chinese
Wall
- types you need to define at least one Chinese Wall Conflict Set. The Chinese
- Wall Conflict Set will allow you to add Chinese Wall types from the list of
- defined Chinese Wall types.
-
- Security Policy Labeling:
- -------------------------
-
- The security policy label section of the web page allows you to create labels
- for classes of virtual machines. The input policy type definitions on the
upper
- part of the web page will provide the available types (Simple Type
Enforcement
- and/or Chinese Wall) that can be assigned to a virtual machine class.
-
- As an example:
- - To add a Virtual Machine class (the name entered will become the label
- that will be used to identify the class):
- - Enter the name of a new class under the Virtual Machine Classes section
- in the entry field above the "New" button.
- - Click the "New" button and the class will be added to the table of
defined
- Virtual Machine classes.
- - To remove a Virtual Machine class:
- - Click the "Delete" link associated with the class in the table of
Virtual
- Machine classes.
-
- Once you have defined one or more Virtual Machine classes, you will be able
to
- add any of the defined Simple Type Enforcement types or Chinese Wall types
to a
- particular Virtual Machine.
-
- You must also define which Virtual Machine class is to be associated with the
- bootstrap domain (or Dom0 domain). By default, the first Virtual Machine
class
- created will be associated as the bootstrap domain.
-
- To save your policy definition file, click on the "Generate XML" button
- on the top of the page. This will present you with a dialog box to save the
- generated XML file on your system. The default name will be
- security_policy.xml which you should change to follow the policy file
- naming conventions based on the policy name that you choose to use.
-
- To get a feel for the tool, you could use one of the example policy
definitions
- files from /etc/xen/acm-security/policies/example as input.
-
-
-7. Hypervisor - OS Security Interface
-=====================================
-
-We currently provide 2 hypercalls through which user operating systems
-can interact with the hypervisor Access Control Module. Examples of
-using them are under "xen_root"/tools/security/python/xensec_tools:
-
-
-I) acm_getdecision -i domainid -l labelname
- Call this example script without arguments to show its usage
- information.
-
- This script enables a domain to retrieve an access control decision
- regarding the STE policy from the hypervisor. It will be used to
- control access to virtual/real resources in hosting domains.
-
- The script can be provided with any combination of domain ids or
- labelnames. Before calling into the hypervisor, labels are translated
- into ssidrefs. The hypervisor then retrieves for any domain id
- paramter the ssidref before deciding access.
-
- Example:
- #/etc/xen/acm-security/scripts/acm_getdecision -l dom_Fun
- -l dom_SystemManagement
- PERMITTED
-
- #/etc/xen/acm-security/scripts/acm_getdecision -i 0 -i 1
- PERMITTED
-
- #/etc/xen/acm-security/scripts/acm_getdecision -i 0 -l dom_Fun
- PERMITTED
-
- #/etc/xen/acm-security/scripts/acm_getdecision -i 0 -l no_label
- ACMError: Label 'nolabel' not found.
-
- Now, assume domain 123454 does not exist:
- #/etc/xen/acm-security/scripts/acm_getdecision -i 123454 -l dom_Fun
- ACMError: Cannot determine decision (Invalid parameter).
-
- Return values:
- * DENIED: access is denied based on the current hypervisor
- policy
-
- * PERMITTED: access is permitted based on the current
-
- * Exception ACMError: one of the parameters was illegal,
- i.e. an unknown label or a
- non-existing domain id
-
-I) acm_getlabel -i domainid
- Retrieves the label of a runing domain. This function can be used
- by domains to determine their own label or (if authorized) the label
- other domains.
-
- Example (result is broken up into different lines to simplify description):
- # /etc/xen/acm-security/scripts/acm_getlabel -i 0
- ('example.chwall.client_v1', <--- policy describing labels etc.
- 'dom_SystemManagement', <--- label name of the domain
- 'CHINESE WALL', <--- policy type
- 65537) <--- hypervisor internal ssidref
-
diff -r 6677b97612a2 -r 16f1f8ac8902 tools/security/install.txt
--- a/tools/security/install.txt Fri Oct 20 10:46:37 2006 +0100
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,87 +0,0 @@
-##
-# install.txt <description to the xen access control architecture>
-#
-# Author:
-# Reiner Sailer 08/15/2005 <sailer@xxxxxxxxxxxxxx>
-# 03/18/2006 update: new labeling
-#
-#
-# This file shows how to activate and install the access control
-# framework for Xen.
-##
-
-
-INSTALLING A SECURITY POLICY IN XEN
-===================================
-
-By default, the access control architecture is disabled in Xen. To
-enable the access control architecture in Xen follow the steps below.
-This description assumes that you want to install the Chinese Wall and
-Simple Type Enforcement policy. Some file names need to be replaced
-below to activate the Chinese Wall OR the Type Enforcement policy
-exclusively (chwall_ste --> {chwall, ste}).
-
-0. build and install the xm man page. It includes the description of
- available management commands for the security policy for Xen and
- the labeling of domains. If not installed by default, you can make
- and install the xm man page as follows:
- # cd "xen_root"/doc
- # make install
- Then, use man xm to read it:
- # man xm
-
-1. enable access control in Xen
- # cd "xen_root"
- # edit/xemacs/vi Config.mk
-
- change the lines:
- ACM_SECURITY ?= n
- to:
- ACM_SECURITY ?= y
-
- Now the hypervisor will boot into the policy that is specified
- in the grub configuration. If you would like to boot into a
- specific policy (even if you can't specify a boot policy but
- need to set the policy later using the 'xensec_tool
- loadpolicy'), then use the other config parameter to change
- from NULL to any other default policy, e.g.:
- ACM_DEFAULT_SECURITY_POLICY ?=
ACM_CHINESE_WALL_AND_SIMPLE_TYPE_ENFORCEMENT_POLICY
-
- # make dist
- # ./install.sh
-
-2. Build acm and policy tools and create boot-able policy:
- # cd tools/security
- # make install
-
- For description of the following commands, please see the xm
- man page (docs/man1/xm.1). If it is not built, then you can
- create it manually: cd "xen_root"/docs; make; man man1/xm.1
-
- Step1: Building binary version of an example policy:
- # xm makepolicy example.chwall_ste.client_v1
- # xm cfgbootpolicy example.chwall_ste.client_v1
-
- Please verify boot entry in /boot/grub/grub.conf (or menu.lst):
- title Xen (2.6.16)
- root (hd0,0)
- kernel /xen.gz dom0_mem=2000000 console=vga
- module /vmlinuz-2.6.16-xen ro root=/dev/VolGroup00/LogVol00 rhgb
- module /initrd-2.6.165-xen-U.img
- module /example.chwall_ste.client_v1.bin
-
-3. reboot into the newly compiled hypervisor
-
- after boot
- # xm dmesg should show an entry about the policy being loaded
- during the boot process
-
- # xm dumppolicy
- should print the new binary policy representation
- including the policy name example.chwall_ste.client_v1
-
- # xm list --label
- should show security label names behind the running domains
-
-For more information about how to use the security-enabled Xen, see
-the examples.txt file in this directory.
_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog
|
Home