direct-io.hg

changeset 5515:228f78f614cb

bitkeeper revision 1.1718.1.8 (42b7436bQ2MohyJ9wW6onfFsyW6VGg)

shype4xen_readme.txt:
new file
author smh22@firebug.cl.cam.ac.uk
date Mon Jun 20 22:30:03 2005 +0000 (2005-06-20)
parents aa52b853c28b
children 3699b115059d
files .rootkeys docs/misc/shype4xen_readme.txt
line diff
     1.1 --- a/.rootkeys	Mon Jun 20 22:28:08 2005 +0000
     1.2 +++ b/.rootkeys	Mon Jun 20 22:30:03 2005 +0000
     1.3 @@ -21,6 +21,7 @@ 412f4bd9sm5mCQ8BkrgKcAKZGadq7Q docs/misc
     1.4  420b949cy9ZGzED74Fz_DaWlK7tT4g docs/misc/crashdb.txt
     1.5  4251a1f82AexscYEiF4Iku8Gc_kWfQ docs/misc/grant-tables.txt
     1.6  424d462b5GuApQ_NyMsRFt9LbrsWow docs/misc/sedf_scheduler_mini-HOWTO.txt
     1.7 +42b7434c-M2l4Og0klGf6xSAARqa2w docs/misc/shype4xen_readme.txt
     1.8  40d6ccbfKKBq8jE0ula4eHEzBiQuDA docs/misc/xen_config.html
     1.9  410a4c2bAO_m_l4RsiiPHnZ4ixHWbQ docs/misc/xend.tex
    1.10  3f9e7d564bWFB-Czjv1qdmE6o0GqNg docs/src/interface.tex
     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/docs/misc/shype4xen_readme.txt	Mon Jun 20 22:30:03 2005 +0000
     2.3 @@ -0,0 +1,580 @@
     2.4 +Copyright: IBM Corporation (C)
     2.5 +20 June 2005
     2.6 +Author: Reiner Sailer
     2.7 +
     2.8 +This document is a very short introduction into the sHype access control 
     2.9 +security architecture implementation and how it is perceived by users. It 
    2.10 +is a very preliminary draft  for the courageous ones to get "their feet wet" 
    2.11 +and to be able to give feedback (via the xen-devel/xense-devel mailing lists).
    2.12 +
    2.13 +Install:
    2.14 +
    2.15 +cd into xeno-unstable.bk 
    2.16 +(use --dry-run option if you want to test the patch only)
    2.17 +patch -p1 -g0 < *tools.diff
    2.18 +patch -p1 -g0 < *xen.diff
    2.19 +
    2.20 +(no rejects, probably some line offsets)
    2.21 +
    2.22 +make uninstall; make mrproper; make; ./install.sh should install the default 
    2.23 +sHype into Xen (rebuild your initrd images if necessary). Reboot.
    2.24 +
    2.25 +Debug output: there are two triggers for debug output:
    2.26 +a) General sHype debug:
    2.27 +    xeno-unstable.bk/xen/include/public/acm.h
    2.28 +    undefine ACM_DEBUG to switch this debug off
    2.29 +
    2.30 +b) sHype enforcement hook trace: This prints a small trace for each enforcement 
    2.31 +hook that is executed. The trigger is in
    2.32 +    xeno-unstable.bk/xen/include/acm/acm_hooks.h
    2.33 +    undefine ACM_TRACE_MODE to switch this debug off
    2.34 +
    2.35 +1. The default NULL policy
    2.36 +***************************
    2.37 +When you apply the patches and startup xen, you should at first not notice any 
    2.38 +difference because the default policy is the "NULL" policy, which as the name 
    2.39 +implies does not enforce anything.
    2.40 +
    2.41 +However, when you try
    2.42 +
    2.43 +[root@laptop policy]# xm list
    2.44 +Name              Id  Mem(MB)  CPU  State  Time(s)  Console  SSID-REF
    2.45 +Domain-0           0      620   0  r----     25.6            default
    2.46 +
    2.47 +You might detect a new parameter "SSID-REF" displayed for domains. This 
    2.48 +parameter describes the subject security identifier reference of the domain. It 
    2.49 +is shown as "default" since there is no policy to be enforced.
    2.50 +
    2.51 +To display the currently enforced policy, use the policy tool under xeno-
    2.52 +unstable.bk/tools/policy: policy_tool getpolicy. You should see output like the 
    2.53 +one below.
    2.54 +
    2.55 +[root@laptop policy]#./policy_tool getpolicy
    2.56 +
    2.57 +Policy dump:
    2.58 +============
    2.59 +Magic     = 1debc.
    2.60 +PolVer    = aaaa0000.
    2.61 +Len       = 14.
    2.62 +Primary   = NULL policy (c=0, off=14).
    2.63 +Secondary = NULL policy (c=0, off=14).
    2.64 +No primary policy (NULL).
    2.65 +No secondary policy (NULL).
    2.66 +
    2.67 +Policy dump End.
    2.68 +
    2.69 +Since this is a dump of a binary policy, it's not pretty. The important parts 
    2.70 +are the "Primary" and "Secondary" policy fields set to "NULL policy". sHype 
    2.71 +currently allows to set two independent policies; thus the two SSID-REF parts 
    2.72 +shown in 'xm list'. Right here: primary policy only means this policy is 
    2.73 +checked first, the secondary policy is checked if the primary results in 
    2.74 +"permitted access". The result of the combined policy is "permitted" if both 
    2.75 +policies return permitted (NULL policy always returns permitted). The result is 
    2.76 +"denied" if at least one of the policies returns "denied". Look into xeno-
    2.77 +unstable.bk/xen/include/acm/acm_hooks.h for the general hook structure 
    2.78 +integrating the policy decisions (if you like, you won't need it for the rest 
    2.79 +of the Readme file).
    2.80 +
    2.81 +2. Setting Chinese Wall and Simple Type Enforcement policies:
    2.82 +*************************************************************
    2.83 +
    2.84 +We'll get fast to the point. However, in order to understand what we are doing, 
    2.85 +we must at least understand the purpose of the policies that we are going to 
    2.86 +enforce. The two policies presented here are just examples and the 
    2.87 +implementation encourages adding new policies easily.
    2.88 +
    2.89 +2.1. Chinese Wall policy: "decides whether a domain can be started based on 
    2.90 +this domain's ssidref and the ssidrefs of the currently running domains". 
    2.91 +Generally, the Chinese wall policy allows specifying certain types (or classes 
    2.92 +or categories, whatever the preferred word) that conflict; we usually assign a 
    2.93 +type to a workload and the set of types of those workloads running in a domain 
    2.94 +make up the type set for this domain.  Each domain is assigned a set of types 
    2.95 +through its SSID-REF (we register Chinese Wall as primary policy, so the 
    2.96 +ssidref used for determining the Chinese Wall types is the one annotated with 
    2.97 +"p:" in xm list) since each SSID-REF points at a set of types. We'll see how 
    2.98 +SSIDREFs are represented in Xen later when we will look at the policy. (A good 
    2.99 +read for Chinese Wall is: Brewer/Nash The Chinese Wall Security Policy 1989.)
   2.100 +
   2.101 +So let's assume the Chinese Wall policy we are running distinguishes 10 types: 
   2.102 +t0 ... t9. Let us assume further that each SSID-REF points to a set that 
   2.103 +includes exactly one type (attached to domains that run workloads of a single 
   2.104 +type). SSID-REF 0 points to {t0}, ssidref 1 points to {t1} ... 9 points to 
   2.105 +{t9}. [This is actually the example policy we are going to push into xen later]
   2.106 +
   2.107 +Now the Chinese Wall policy allows you to define "Conflict type sets" and it 
   2.108 +guarantees that of any conflict set at most one type is "running" at any time. 
   2.109 +As an example, we have defined 2 conflict set: {t2, t3} and {t0, t5, t6}. 
   2.110 +Specifying these conflict sets, sHype ensures that at most one type of each set 
   2.111 +is running (either t2 or t3 but not both; either t0 or t5 or t6 but not 
   2.112 +multiple of them).
   2.113 +
   2.114 +The effect is that administrators can define which workload types cannot run 
   2.115 +simultaneously on a single Xen system. This is useful to limit the covert 
   2.116 +timing channels between such payloads or to ensure that payloads don't 
   2.117 +interfere with each other through existing resource dependencies.
   2.118 +
   2.119 +2.2. Simple Type Enforcement (ste) policy: "decides whether two domains can 
   2.120 +share data, e.g., setup event channels or grant tables to each other, based on 
   2.121 +the two domains' ssidref. This, as the name says, is a simple policy. Think of 
   2.122 +each type as of a single color. Each domain has one or more colors, i.e., the 
   2.123 +domains ssid for the ste policy points to a set that has set one or multiple 
   2.124 +types. Let us assume in our example policy we differentiate 5 colors (types) 
   2.125 +and define 5 different ssids referenced by ssidref=0..4. Each ssid shall have 
   2.126 +exactly one type set, i.e., describes a uni-color. Only ssid(0) has all types 
   2.127 +set, i.e., has all defined colors.
   2.128 +
   2.129 +Sharing is enforced by the ste policy by requiring that two domains that want 
   2.130 +to establish an event channel or grant pages to each other must have a common 
   2.131 +color. Currently all domains communicate through DOM0 by default; i.e., Domain0 
   2.132 +will necessarily have all colors to be able to create domains (thus, we will 
   2.133 +assign ssidref(0) to Domain0 in our example below.
   2.134 +
   2.135 +More complex mandatory access control policies governing sharing will follow; 
   2.136 +such policies are more sophisticated than the "color" scheme above by allowing 
   2.137 +more flexible (and complex :_) access control decisions than "share a color" or 
   2.138 +"don't share a color" and will be able to express finer-grained policies.
   2.139 +
   2.140 +
   2.141 +2.3 Binary Policy:
   2.142 +In the future, we will have a policy tool that takes as input a more humane 
   2.143 +policy description, using types such as development, home-banking, donated-
   2.144 +Grid, CorpA-Payload ... and translates the respective policy into what we see 
   2.145 +today as the binary policy using 1s and 0s and sets of them. For now, we must 
   2.146 +live with the binary policy when working with sHype.
   2.147 +
   2.148 +    
   2.149 +2.4 Exemplary use of a real sHype policy on Xen. To activate a real policy, 
   2.150 +edit the file (yes, this will soon be a compile option):
   2.151 +  xeno-unstable.bk/xen/include/public/acm.h
   2.152 +  Change: #define ACM_USE_SECURITY_POLICY ACM_NULL_POLICY
   2.153 +   To : #define ACM_USE_SECURITY_POLICY ACM_CHINESE_WALL_AND_SIMPLE_TYPE_ENFORCEMENT_POLICY
   2.154 +   cd xeno-unstable.bk
   2.155 +   make mrproper
   2.156 +   make uninstall (manually remove /etc/xen.old if necessary)
   2.157 +   make
   2.158 +   ./install.sh      (recreate your kernel initrd's if necessary)
   2.159 +   Reboot into new xen.gz
   2.160 +     
   2.161 +After booting, check out 'xm dmesg'; should show somewhere in the middle:
   2.162 +
   2.163 +(XEN) acm_init: Enforcing Primary CHINESE WALL policy, Secondary SIMPLE TYPE 
   2.164 +ENFORCEMENT policy.
   2.165 +
   2.166 +Even though you can activate those policies in any combination and also 
   2.167 +independently, the policy tool currently only supports setting the policy for 
   2.168 +the above combination.
   2.169 +
   2.170 +Now look at the minimal startup policy with:
   2.171 +                xeno-unstable.bk/tools/policytool getpolicy
   2.172 +
   2.173 +You should see something like:
   2.174 +
   2.175 +[root@laptop policy]# ./policy_tool getpolicy
   2.176 +
   2.177 +Policy dump:
   2.178 +============
   2.179 +Magic     = 1debc.
   2.180 +PolVer    = aaaa0000.
   2.181 +Len       = 36.
   2.182 +Primary   = CHINESE WALL policy (c=1, off=14).
   2.183 +Secondary = SIMPLE TYPE ENFORCEMENT policy (c=2, off=2c).
   2.184 +
   2.185 +
   2.186 +Chinese Wall policy:
   2.187 +====================
   2.188 +Max Types     = 1.
   2.189 +Max Ssidrefs  = 1.
   2.190 +Max ConfSets  = 1.
   2.191 +Ssidrefs Off  = 10.
   2.192 +Conflicts Off = 12.
   2.193 +Runing T. Off = 14.
   2.194 +C. Agg. Off   = 16.
   2.195 +
   2.196 +SSID To CHWALL-Type matrix:
   2.197 +
   2.198 +   ssidref 0:  00 
   2.199 +
   2.200 +Confict Sets:
   2.201 +
   2.202 +   c-set 0:    00 
   2.203 +
   2.204 +Running
   2.205 +Types:         00 
   2.206 +
   2.207 +Conflict
   2.208 +Aggregate Set: 00 
   2.209 +
   2.210 +
   2.211 +Simple Type Enforcement policy:
   2.212 +===============================
   2.213 +Max Types     = 1.
   2.214 +Max Ssidrefs  = 1.
   2.215 +Ssidrefs Off  = 8.
   2.216 +
   2.217 +SSID To STE-Type matrix:
   2.218 +
   2.219 +   ssidref 0: 01 
   2.220 +
   2.221 +
   2.222 +Policy dump End.
   2.223 +
   2.224 +This is a minimal policy (of little use), except it will disable starting any 
   2.225 +domain that does not have ssidref set to 0x0. The Chinese Wall policy has 
   2.226 +nothing to enforce and the ste policy only knows one type, which is set for the 
   2.227 +only defined ssidref.
   2.228 +
   2.229 +The item that defines the ssidref in a domain configuration is:
   2.230 +
   2.231 +ssidref = 0x12345678
   2.232 +
   2.233 +Where ssidref is interpreted as a 32bit number, where the lower 16bits become 
   2.234 +the ssidref for the primary policy and the higher 16bits become the ssidref for 
   2.235 +the secondary policy. sHype currently supports two policies but this is an 
   2.236 +implementation decision and can be extended if necessary.
   2.237 +
   2.238 +This reference defines the security information of a domain. The meaning of the 
   2.239 +SSID-REF depends on the policy, so we explain it when we explain the real 
   2.240 +policies.
   2.241 +
   2.242 +
   2.243 +Setting a new Security Policy:
   2.244 +******************************
   2.245 +The policy tool with all its current limitations has one usable example policy 
   2.246 +compiled-in. Please try at this time to use the setpolicy command:
   2.247 +       xeno-unstable.bk/tools/policy/policy_tool setpolicy
   2.248 +
   2.249 +You should see a dump of the policy you are setting. It should say at the very 
   2.250 +end: 
   2.251 +
   2.252 +Policy successfully set.
   2.253 +
   2.254 +Now try to dump the currently enforced policy, which is the policy we have just 
   2.255 +set and the dynamic security state information of this policy 
   2.256 +(<<< ... some additional explanations)
   2.257 +
   2.258 +[root@laptop policy]# ./policy_tool getpolicy
   2.259 +
   2.260 +Policy dump:
   2.261 +============
   2.262 +Magic     = 1debc.
   2.263 +PolVer    = aaaa0000.
   2.264 +Len       = 112.
   2.265 +Primary   = CHINESE WALL policy (c=1, off=14).
   2.266 +Secondary = SIMPLE TYPE ENFORCEMENT policy (c=2, off=d8).
   2.267 +
   2.268 +
   2.269 +Chinese Wall policy:
   2.270 +====================
   2.271 +Max Types     = a.
   2.272 +Max Ssidrefs  = 5.
   2.273 +Max ConfSets  = 2.
   2.274 +Ssidrefs Off  = 10.
   2.275 +Conflicts Off = 74.
   2.276 +Runing T. Off = 9c.
   2.277 +C. Agg. Off   = b0.
   2.278 +
   2.279 +SSID To CHWALL-Type matrix:
   2.280 +
   2.281 +   ssidref 0:  01 00 00 00 00 00 00 00 00 00  <<< type0 is set for ssidref0
   2.282 +   ssidref 1:  00 01 00 00 00 00 00 00 00 00 
   2.283 +   ssidref 2:  00 00 01 00 00 00 00 00 00 00 
   2.284 +   ssidref 3:  00 00 00 01 00 00 00 00 00 00 
   2.285 +   ssidref 4:  00 00 00 00 01 00 00 00 00 00  <<< type4 is set for ssidref4
   2.286 +                                              <<< types 5-9 are unused
   2.287 +Confict Sets:
   2.288 +
   2.289 +   c-set 0:    00 00 01 01 00 00 00 00 00 00  <<< type2 and type3 never run together
   2.290 +   c-set 1:    01 00 00 00 00 01 01 00 00 00  <<< only one of types 0, 5 or 6 
   2.291 +                                              <<<   can run simultaneously
   2.292 +Running
   2.293 +Types:         01 00 00 00 00 00 00 00 00 00  <<< ref-count for types of running domains
   2.294 +
   2.295 +Conflict
   2.296 +Aggregate Set: 00 00 00 00 00 01 01 00 00 00  <<< aggregated set of types that                  
   2.297 +                                              <<< cannot run because they 
   2.298 +                                              <<< are in conflict set 1 and
   2.299 +                                              <<< (domain 0 is running w t0)
   2.300 +                                             
   2.301 +
   2.302 +Simple Type Enforcement policy:
   2.303 +===============================
   2.304 +Max Types     = 5.
   2.305 +Max Ssidrefs  = 5.
   2.306 +Ssidrefs Off  = 8.
   2.307 +
   2.308 +SSID To STE-Type matrix:
   2.309 +
   2.310 +   ssidref 0: 01 01 01 01 01                  <<< ssidref0 points to a set that                  
   2.311 +                                              <<< has all types set (colors)
   2.312 +   ssidref 1: 00 01 00 00 00                  <<< ssidref1 has color1 set
   2.313 +   ssidref 2: 00 00 01 00 00                  <<< ...
   2.314 +   ssidref 3: 00 00 00 01 00 
   2.315 +   ssidref 4: 00 00 00 00 01 
   2.316 +
   2.317 +
   2.318 +Policy dump End.
   2.319 +
   2.320 +
   2.321 +This is a small example policy with which we will demonstrate the enforcement.
   2.322 +
   2.323 +Starting Domains with policy enforcement
   2.324 +========================================
   2.325 +Now let us play with this policy. 
   2.326 +
   2.327 +Define 3 or 4 domain configurations. I use the following config using a ramdisk 
   2.328 +only and about 8MBytes of memory for each DomU (test purposes):
   2.329 +
   2.330 +#-------configuration xmsec1-------------------------
   2.331 +kernel = "/boot/vmlinuz-2.6.11-xenU"
   2.332 +ramdisk="/boot/U1_ramdisk.img"
   2.333 +#security reference identifier
   2.334 +ssidref= 0x00010001
   2.335 +memory = 10
   2.336 +name = "xmsec1"
   2.337 +cpu = -1   # leave to Xen to pick
   2.338 +# Number of network interfaces. Default is 1.
   2.339 +nics=1
   2.340 +dhcp="dhcp"
   2.341 +#-----------------------------------------------------
   2.342 +
   2.343 +xmsec2 and xmsec3 look the same except for the name and the ssidref line. Use 
   2.344 +your domain config file and add "ssidref = 0x00010001" to the first (xmsec1),  
   2.345 +"ssidref= 0x00020002" to the second (call it xmsec2), and "ssidref=0x00030003"  
   2.346 +to the third (we will call this one xmsec3).
   2.347 +
   2.348 +First start xmsec1: xm create -c xmsec1 (succeeds)
   2.349 +
   2.350 +Then
   2.351 +[root@laptop policy]# xm list 
   2.352 +Name              Id  Mem(MB)  CPU  State  Time(s)  Console  SSID-REF
   2.353 +Domain-0           0      620   0  r----     42.3            s:00/p:00
   2.354 +xmnosec            1        9   0  -b---      0.3    9601    s:00/p:05
   2.355 +xmsec1             2        9   0  -b---      0.2    9602    s:01/p:01
   2.356 +
   2.357 +Shows a new domain xmsec1 running with primary (here: chinese wall) ssidref 1 
   2.358 +and secondary (here: simple type enforcement) ssidref 1. The ssidrefs are  
   2.359 +independent and can differ for a domain.
   2.360 +
   2.361 +[root@laptop policy]# ./policy_tool getpolicy
   2.362 +
   2.363 +Policy dump:
   2.364 +============
   2.365 +Magic     = 1debc.
   2.366 +PolVer    = aaaa0000.
   2.367 +Len       = 112.
   2.368 +Primary   = CHINESE WALL policy (c=1, off=14).
   2.369 +Secondary = SIMPLE TYPE ENFORCEMENT policy (c=2, off=d8).
   2.370 +
   2.371 +
   2.372 +Chinese Wall policy:
   2.373 +====================
   2.374 +Max Types     = a.
   2.375 +Max Ssidrefs  = 5.
   2.376 +Max ConfSets  = 2.
   2.377 +Ssidrefs Off  = 10.
   2.378 +Conflicts Off = 74.
   2.379 +Runing T. Off = 9c.
   2.380 +C. Agg. Off   = b0.
   2.381 +
   2.382 +SSID To CHWALL-Type matrix:
   2.383 +
   2.384 +   ssidref 0:  01 00 00 00 00 00 00 00 00 00
   2.385 +   ssidref 1:  00 01 00 00 00 00 00 00 00 00
   2.386 +   ssidref 2:  00 00 01 00 00 00 00 00 00 00
   2.387 +   ssidref 3:  00 00 00 01 00 00 00 00 00 00
   2.388 +   ssidref 4:  00 00 00 00 01 00 00 00 00 00
   2.389 +
   2.390 +Confict Sets:
   2.391 +
   2.392 +   c-set 0:    00 00 01 01 00 00 00 00 00 00
   2.393 +   c-set 1:    01 00 00 00 00 01 01 00 00 00   <<< t1 is not part of any c-set
   2.394 +
   2.395 +Running
   2.396 +Types:         01 01 00 00 00 00 00 00 00 00   <<< xmsec1 has ssidref 1->type1
   2.397 +                  ^^                           <<< ref-count at position 1 incr
   2.398 +Conflict
   2.399 +Aggregate Set: 00 00 00 00 00 01 01 00 00 00   <<< domain 1 was allowed to       
   2.400 +                                               <<< start since type 1 was not
   2.401 +                                               <<< in conflict with running 
   2.402 +                                               <<< types
   2.403 +                                            
   2.404 +Simple Type Enforcement policy:
   2.405 +===============================
   2.406 +Max Types     = 5.
   2.407 +Max Ssidrefs  = 5.
   2.408 +Ssidrefs Off  = 8.
   2.409 +
   2.410 +SSID To STE-Type matrix:
   2.411 +
   2.412 +   ssidref 0: 01 01 01 01 01           <<< the ste policy does not maintain; we
   2.413 +   ssidref 1: 00 01 00 00 00   <--     <<< see that domain xmsec1 has ste 
   2.414 +   ssidref 2: 00 00 01 00 00           <<< ssidref1->type1 and has this type in
   2.415 +   ssidref 3: 00 00 00 01 00           <<< common with dom0
   2.416 +   ssidref 4: 00 00 00 00 01
   2.417 +
   2.418 +
   2.419 +Policy dump End.
   2.420 +
   2.421 +Look at sHype output in xen dmesg:
   2.422 +
   2.423 +[root@laptop xen]# xm dmesg
   2.424 +.
   2.425 +.
   2.426 +[somewhere near the very end]
   2.427 +(XEN) chwall_init_domain_ssid: determined chwall_ssidref to 1.
   2.428 +(XEN) ste_init_domain_ssid.
   2.429 +(XEN) ste_init_domain_ssid: determined ste_ssidref to 1.
   2.430 +(XEN) acm_init_domain_ssid: Instantiated individual ssid for domain 0x01.
   2.431 +(XEN) chwall_post_domain_create.
   2.432 +(XEN) ste_pre_eventchannel_interdomain.
   2.433 +(XEN) ste_pre_eventchannel_interdomain: (evtchn 0 --> 1) common type #01.
   2.434 +(XEN) shype_authorize_domops.
   2.435 +(XEN) ste_pre_eventchannel_interdomain.
   2.436 +(XEN) ste_pre_eventchannel_interdomain: (evtchn 0 --> 1) common type #01.
   2.437 +(XEN) ste_pre_eventchannel_interdomain.
   2.438 +(XEN) ste_pre_eventchannel_interdomain: (evtchn 0 --> 1) common type #01.
   2.439 +
   2.440 +
   2.441 +You can see that the chinese wall policy does not complain and that the ste 
   2.442 +policy makes three access control decisions for three event-channels setup 
   2.443 +between domain 0 and the new domain 1. Each time, the two domains share the 
   2.444 +type1 and setting up the eventchannel is permitted.
   2.445 +
   2.446 +
   2.447 +Starting up a second domain xmsec2:
   2.448 +
   2.449 +[root@laptop xen]# xm create -c xmsec2
   2.450 +Using config file "xmsec2".
   2.451 +Started domain xmsec2, console on port 9602
   2.452 +************ REMOTE CONSOLE: CTRL-] TO QUIT ********
   2.453 +Linux version 2.6.11-xenU (root@laptop.home.org) (gcc version 3.4.2 20041017 
   2.454 +(Red Hat 3.4.2-6.fc3)) #1 Wed Mar 30 13:14:31 EST 2005
   2.455 +.
   2.456 +.
   2.457 +.
   2.458 +[root@laptop policy]# xm list
   2.459 +Name              Id  Mem(MB)  CPU  State  Time(s)  Console  SSID-REF
   2.460 +Domain-0           0      620   0  r----     71.7            s:00/p:00
   2.461 +xmsec1             1        9   0  -b---      0.3    9601    s:01/p:01
   2.462 +xmsec2             2        7   0  -b---      0.3    9602    s:02/p:02   << our domain runs both policies with ssidref 2
   2.463 +
   2.464 +
   2.465 +[root@laptop policy]# ./policy_tool getpolicy
   2.466 +
   2.467 +Policy dump:
   2.468 +============
   2.469 +Magic     = 1debc.
   2.470 +PolVer    = aaaa0000.
   2.471 +Len       = 112.
   2.472 +Primary   = CHINESE WALL policy (c=1, off=14).
   2.473 +Secondary = SIMPLE TYPE ENFORCEMENT policy (c=2, off=d8).
   2.474 +
   2.475 +
   2.476 +Chinese Wall policy:
   2.477 +====================
   2.478 +Max Types     = a.
   2.479 +Max Ssidrefs  = 5.
   2.480 +Max ConfSets  = 2.
   2.481 +Ssidrefs Off  = 10.
   2.482 +Conflicts Off = 74.
   2.483 +Runing T. Off = 9c.
   2.484 +C. Agg. Off   = b0.
   2.485 +
   2.486 +SSID To CHWALL-Type matrix:
   2.487 +
   2.488 +   ssidref 0:  01 00 00 00 00 00 00 00 00 00
   2.489 +   ssidref 1:  00 01 00 00 00 00 00 00 00 00
   2.490 +   ssidref 2:  00 00 01 00 00 00 00 00 00 00   <<< our domain has type 2 set
   2.491 +   ssidref 3:  00 00 00 01 00 00 00 00 00 00
   2.492 +   ssidref 4:  00 00 00 00 01 00 00 00 00 00
   2.493 +
   2.494 +Confict Sets:
   2.495 +
   2.496 +   c-set 0:    00 00 01 01 00 00 00 00 00 00   <<< t2 is in c-set0 with type 3
   2.497 +   c-set 1:    01 00 00 00 00 01 01 00 00 00
   2.498 +
   2.499 +Running
   2.500 +Types:         01 01 01 00 00 00 00 00 00 00   <<< t2 is running since the 
   2.501 +                     ^^                        <<< current aggregate conflict
   2.502 +                                               <<< set (see above) does not 
   2.503 +                                               <<< include type 2
   2.504 +Conflict
   2.505 +Aggregate Set: 00 00 00 01 00 01 01 00 00 00   <<< type 3 is added to the 
   2.506 +                                               <<< conflict aggregate
   2.507 +
   2.508 +
   2.509 +Simple Type Enforcement policy:
   2.510 +===============================
   2.511 +Max Types     = 5.
   2.512 +Max Ssidrefs  = 5.
   2.513 +Ssidrefs Off  = 8.
   2.514 +
   2.515 +SSID To STE-Type matrix:
   2.516 +
   2.517 +   ssidref 0: 01 01 01 01 01
   2.518 +   ssidref 1: 00 01 00 00 00
   2.519 +   ssidref 2: 00 00 01 00 00
   2.520 +   ssidref 3: 00 00 00 01 00
   2.521 +   ssidref 4: 00 00 00 00 01
   2.522 +
   2.523 +
   2.524 +Policy dump End.
   2.525 +
   2.526 +
   2.527 +The sHype xen dmesg output looks similar to the one above when starting the 
   2.528 +first domain.
   2.529 +
   2.530 +Now we start xmsec3 and it has ssidref3. Thus, it tries to run as type3 which 
   2.531 +conflicts with running type2 (from xmsec2). As expected, creating this domain 
   2.532 +fails for security policy enforcement reasons.
   2.533 +
   2.534 +[root@laptop xen]# xm create -c xmsec3
   2.535 +Using config file "xmsec3".
   2.536 +Error: Error creating domain: (22, 'Invalid argument')
   2.537 +[root@laptop xen]#
   2.538 +
   2.539 +[root@laptop xen]# xm dmesg
   2.540 +.
   2.541 +.
   2.542 +[somewhere near the very end]
   2.543 +(XEN) chwall_pre_domain_create.
   2.544 +(XEN) chwall_pre_domain_create: CHINESE WALL CONFLICT in type 03.
   2.545 +
   2.546 +xmsec3 ssidref3 points to type3, which is in the current conflict aggregate 
   2.547 +set. This domain cannot start until domain xmsec2 is destroyed, at which time 
   2.548 +the aggregate conflict set is reduced and type3 is excluded from it. Then, 
   2.549 +xmsec3 can start. Of course, afterwards, xmsec2 cannot be restarted. Try it.
   2.550 +
   2.551 +3. Policy tool
   2.552 +**************
   2.553 +toos/policy/policy_tool.c
   2.554 +
   2.555 +a) ./policy_tool getpolicy
   2.556 +      prints the currently enforced policy
   2.557 +      (see for example section 1.)
   2.558 +
   2.559 +b) ./policy_tool setpolicy
   2.560 +      sets a predefined and hardcoded security
   2.561 +      policy (the one described in section 2.)
   2.562 +
   2.563 +c) ./policy_tool dumpstats
   2.564 +      prints some status information about the caching
   2.565 +      of access control decisions (number of cache hits
   2.566 +      and number of policy evaluations for grant_table
   2.567 +      and event channels).
   2.568 +
   2.569 +d) ./policy_tool loadpolicy <binary_policy_file>
   2.570 +      sets the policy defined in the <binary_policy_file>
   2.571 +      please use the policy_processor that is posted to this
   2.572 +      mailing list to create such a binary policy from an XML
   2.573 +      policy description
   2.574 +
   2.575 +4. Policy interface:
   2.576 +********************
   2.577 +The Policy interface is working in "network-byte-order" (big endian). The reason for this
   2.578 +is that policy files/management should be portable and independent of the platforms.
   2.579 +
   2.580 +Our policy interface enables managers to create a single binary policy file in a trusted
   2.581 +environment and distributed it to multiple systems for enforcement.
   2.582 +
   2.583 +====================end-of file=======================================
   2.584 \ No newline at end of file