This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-changelog] shype4xen_readme.txt:

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] shype4xen_readme.txt:
From: BitKeeper Bot <riel@xxxxxxxxxxx>
Date: Mon, 20 Jun 2005 22:30:03 +0000
Delivery-date: Mon, 20 Jun 2005 23:00:41 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: Xen Development List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
ChangeSet 1.1726, 2005/06/20 23:30:03+01:00, smh22@xxxxxxxxxxxxxxxxxxxx

          new file

 shype4xen_readme.txt |  580 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 580 insertions(+)

diff -Nru a/docs/misc/shype4xen_readme.txt b/docs/misc/shype4xen_readme.txt
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/docs/misc/shype4xen_readme.txt    2005-06-20 19:01:48 -04:00
@@ -0,0 +1,580 @@
+Copyright: IBM Corporation (C)
+20 June 2005
+Author: Reiner Sailer
+This document is a very short introduction into the sHype access control 
+security architecture implementation and how it is perceived by users. It 
+is a very preliminary draft  for the courageous ones to get "their feet wet" 
+and to be able to give feedback (via the xen-devel/xense-devel mailing lists).
+cd into xeno-unstable.bk 
+(use --dry-run option if you want to test the patch only)
+patch -p1 -g0 < *tools.diff
+patch -p1 -g0 < *xen.diff
+(no rejects, probably some line offsets)
+make uninstall; make mrproper; make; ./install.sh should install the default 
+sHype into Xen (rebuild your initrd images if necessary). Reboot.
+Debug output: there are two triggers for debug output:
+a) General sHype debug:
+    xeno-unstable.bk/xen/include/public/acm.h
+    undefine ACM_DEBUG to switch this debug off
+b) sHype enforcement hook trace: This prints a small trace for each 
+hook that is executed. The trigger is in
+    xeno-unstable.bk/xen/include/acm/acm_hooks.h
+    undefine ACM_TRACE_MODE to switch this debug off
+1. The default NULL policy
+When you apply the patches and startup xen, you should at first not notice any 
+difference because the default policy is the "NULL" policy, which as the name 
+implies does not enforce anything.
+However, when you try
+[root@laptop policy]# xm list
+Name              Id  Mem(MB)  CPU  State  Time(s)  Console  SSID-REF
+Domain-0           0      620   0  r----     25.6            default
+You might detect a new parameter "SSID-REF" displayed for domains. This 
+parameter describes the subject security identifier reference of the domain. 
+is shown as "default" since there is no policy to be enforced.
+To display the currently enforced policy, use the policy tool under xeno-
+unstable.bk/tools/policy: policy_tool getpolicy. You should see output like 
+one below.
+[root@laptop policy]#./policy_tool getpolicy
+Policy dump:
+Magic     = 1debc.
+PolVer    = aaaa0000.
+Len       = 14.
+Primary   = NULL policy (c=0, off=14).
+Secondary = NULL policy (c=0, off=14).
+No primary policy (NULL).
+No secondary policy (NULL).
+Policy dump End.
+Since this is a dump of a binary policy, it's not pretty. The important parts 
+are the "Primary" and "Secondary" policy fields set to "NULL policy". sHype 
+currently allows to set two independent policies; thus the two SSID-REF parts 
+shown in 'xm list'. Right here: primary policy only means this policy is 
+checked first, the secondary policy is checked if the primary results in 
+"permitted access". The result of the combined policy is "permitted" if both 
+policies return permitted (NULL policy always returns permitted). The result 
+"denied" if at least one of the policies returns "denied". Look into xeno-
+unstable.bk/xen/include/acm/acm_hooks.h for the general hook structure 
+integrating the policy decisions (if you like, you won't need it for the rest 
+of the Readme file).
+2. Setting Chinese Wall and Simple Type Enforcement policies:
+We'll get fast to the point. However, in order to understand what we are 
+we must at least understand the purpose of the policies that we are going to 
+enforce. The two policies presented here are just examples and the 
+implementation encourages adding new policies easily.
+2.1. Chinese Wall policy: "decides whether a domain can be started based on 
+this domain's ssidref and the ssidrefs of the currently running domains". 
+Generally, the Chinese wall policy allows specifying certain types (or classes 
+or categories, whatever the preferred word) that conflict; we usually assign a 
+type to a workload and the set of types of those workloads running in a domain 
+make up the type set for this domain.  Each domain is assigned a set of types 
+through its SSID-REF (we register Chinese Wall as primary policy, so the 
+ssidref used for determining the Chinese Wall types is the one annotated with 
+"p:" in xm list) since each SSID-REF points at a set of types. We'll see how 
+SSIDREFs are represented in Xen later when we will look at the policy. (A good 
+read for Chinese Wall is: Brewer/Nash The Chinese Wall Security Policy 1989.)
+So let's assume the Chinese Wall policy we are running distinguishes 10 types: 
+t0 ... t9. Let us assume further that each SSID-REF points to a set that 
+includes exactly one type (attached to domains that run workloads of a single 
+type). SSID-REF 0 points to {t0}, ssidref 1 points to {t1} ... 9 points to 
+{t9}. [This is actually the example policy we are going to push into xen later]
+Now the Chinese Wall policy allows you to define "Conflict type sets" and it 
+guarantees that of any conflict set at most one type is "running" at any time. 
+As an example, we have defined 2 conflict set: {t2, t3} and {t0, t5, t6}. 
+Specifying these conflict sets, sHype ensures that at most one type of each 
+is running (either t2 or t3 but not both; either t0 or t5 or t6 but not 
+multiple of them).
+The effect is that administrators can define which workload types cannot run 
+simultaneously on a single Xen system. This is useful to limit the covert 
+timing channels between such payloads or to ensure that payloads don't 
+interfere with each other through existing resource dependencies.
+2.2. Simple Type Enforcement (ste) policy: "decides whether two domains can 
+share data, e.g., setup event channels or grant tables to each other, based on 
+the two domains' ssidref. This, as the name says, is a simple policy. Think of 
+each type as of a single color. Each domain has one or more colors, i.e., the 
+domains ssid for the ste policy points to a set that has set one or multiple 
+types. Let us assume in our example policy we differentiate 5 colors (types) 
+and define 5 different ssids referenced by ssidref=0..4. Each ssid shall have 
+exactly one type set, i.e., describes a uni-color. Only ssid(0) has all types 
+set, i.e., has all defined colors.
+Sharing is enforced by the ste policy by requiring that two domains that want 
+to establish an event channel or grant pages to each other must have a common 
+color. Currently all domains communicate through DOM0 by default; i.e., 
+will necessarily have all colors to be able to create domains (thus, we will 
+assign ssidref(0) to Domain0 in our example below.
+More complex mandatory access control policies governing sharing will follow; 
+such policies are more sophisticated than the "color" scheme above by allowing 
+more flexible (and complex :_) access control decisions than "share a color" 
+"don't share a color" and will be able to express finer-grained policies.
+2.3 Binary Policy:
+In the future, we will have a policy tool that takes as input a more humane 
+policy description, using types such as development, home-banking, donated-
+Grid, CorpA-Payload ... and translates the respective policy into what we see 
+today as the binary policy using 1s and 0s and sets of them. For now, we must 
+live with the binary policy when working with sHype.
+2.4 Exemplary use of a real sHype policy on Xen. To activate a real policy, 
+edit the file (yes, this will soon be a compile option):
+  xeno-unstable.bk/xen/include/public/acm.h
+   cd xeno-unstable.bk
+   make mrproper
+   make uninstall (manually remove /etc/xen.old if necessary)
+   make
+   ./install.sh      (recreate your kernel initrd's if necessary)
+   Reboot into new xen.gz
+After booting, check out 'xm dmesg'; should show somewhere in the middle:
+(XEN) acm_init: Enforcing Primary CHINESE WALL policy, Secondary SIMPLE TYPE 
+Even though you can activate those policies in any combination and also 
+independently, the policy tool currently only supports setting the policy for 
+the above combination.
+Now look at the minimal startup policy with:
+                xeno-unstable.bk/tools/policytool getpolicy
+You should see something like:
+[root@laptop policy]# ./policy_tool getpolicy
+Policy dump:
+Magic     = 1debc.
+PolVer    = aaaa0000.
+Len       = 36.
+Primary   = CHINESE WALL policy (c=1, off=14).
+Secondary = SIMPLE TYPE ENFORCEMENT policy (c=2, off=2c).
+Chinese Wall policy:
+Max Types     = 1.
+Max Ssidrefs  = 1.
+Max ConfSets  = 1.
+Ssidrefs Off  = 10.
+Conflicts Off = 12.
+Runing T. Off = 14.
+C. Agg. Off   = 16.
+SSID To CHWALL-Type matrix:
+   ssidref 0:  00 
+Confict Sets:
+   c-set 0:    00 
+Types:         00 
+Aggregate Set: 00 
+Simple Type Enforcement policy:
+Max Types     = 1.
+Max Ssidrefs  = 1.
+Ssidrefs Off  = 8.
+SSID To STE-Type matrix:
+   ssidref 0: 01 
+Policy dump End.
+This is a minimal policy (of little use), except it will disable starting any 
+domain that does not have ssidref set to 0x0. The Chinese Wall policy has 
+nothing to enforce and the ste policy only knows one type, which is set for 
+only defined ssidref.
+The item that defines the ssidref in a domain configuration is:
+ssidref = 0x12345678
+Where ssidref is interpreted as a 32bit number, where the lower 16bits become 
+the ssidref for the primary policy and the higher 16bits become the ssidref 
+the secondary policy. sHype currently supports two policies but this is an 
+implementation decision and can be extended if necessary.
+This reference defines the security information of a domain. The meaning of 
+SSID-REF depends on the policy, so we explain it when we explain the real 
+Setting a new Security Policy:
+The policy tool with all its current limitations has one usable example policy 
+compiled-in. Please try at this time to use the setpolicy command:
+       xeno-unstable.bk/tools/policy/policy_tool setpolicy
+You should see a dump of the policy you are setting. It should say at the very 

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] shype4xen_readme.txt:, BitKeeper Bot <=