Hi all, For the past two months our team has worked to integrate the sHype security architecture into Xen. sHype was initially discussed on the Xen development emailing list in http://lists.xensource.com/archives/html/xen-devel/2005-01/msg00519.html and the implementation described here is based on the design published in http://www.research.ibm.com/secure_systems_department/projects/hypervisor. We have attached the stable patches of our port for the group to evaluate. The code successfully enforces "sample" security policies and demonstrates the minimal impact sHype has on both the main Xen code base and on Xen''s run-time performance. (I post the patches here tonight, and will follow up by Thursday with a README and some examples.) The security enforcement hooks cover domain operations, event channels, and also --as far as available-- grant tables. These hooks will also cover save/restore/migrate once these operations are working and stable. Please note that the default policy under these patches is a "NULL" policy. This means that, even after the patches are applied, there will be *no* change to the user or administrator experience until a security policy is explicitly enabled. The sHype port consists of three patches (tested on the xeno-unstable.bk version from March 29 th): 1. shype_4_xeno-unstable.bk_v0.2_xen.diff .. patch that includes the security enforcement code and access control module, the heart of shype; 2. shype_4_xeno-unstable.bk_v0.2_sparse.diff .. kernel patch that includes an additional /proc/xen/policycmd interface using a new policy hypercall to communicate policies between xen and the policy management tool; 3. shype_4_xeno-unstable.bk_v0.2_tools.diff .. tools patch that includes support for a new parameter security subject identifier reference (ssidref) in the domain configuration, as well as a v-e-r-y simple policy tool to set binary policies in xen and to retrieve and dump enforced policies from xen (tools/policytool); in a future version, this tool will read user-defined policies and compile them into the binary policies to be downloaded into xen. If you install the patches, please start with a clean xeno-unstable.bk tree: make mrproper; make uninstall; >patch the code here<; make; ./install.sh. More instructions to follow. Comments/feedback related to these patches are very welcome. Note that I will not be able to read my email from April 1st to 11th. If anyone has any quick questions I will try to answer them before I leave; otherwise, please look through the code at your convenience and let us discuss details once I am back. (Note that the code is still "under development" -- for example, work continues on save/restore support & on revoking resources to enable policy changes at run-time, as well as moving the enforced policy from a hard-coded parameter to a compile-time option). Kindest Regards Reiner Signed-off-by: Reiner Sailer __________________________________________________________ Reiner Sailer, Research Staff Member, Secure Systems Department IBM T J Watson Research Ctr, 19 Skyline Drive, Hawthorne NY 10532 Phone: 914 784 6280 (t/l 863) Fax: 914 784 6205, sailer@us.ibm.com http://www.research.ibm.com/people/s/sailer/
Hi all, For the past two months our team has worked to integrate the sHype security architecture into Xen. sHype was initially discussed on the Xen development emailing list in http://lists.xensource.com/archives/html/xen-devel/2005-01/msg00519.html and the implementation described here is based on the design published in http://www.research.ibm.com/secure_systems_department/projects/hypervisor. We have attached the stable patches of our port for the group to evaluate. The code successfully enforces "sample" security policies and demonstrates the minimal impact sHype has on both the main Xen code base and on Xen''s run-time performance. (I post the patches here tonight, and will follow up by Thursday with a README and some examples.) The security enforcement hooks cover domain operations, event channels, and also --as far as available-- grant tables. These hooks will also cover save/restore/migrate once these operations are working and stable. Please note that the default policy under these patches is a "NULL" policy. This means that, even after the patches are applied, there will be *no* change to the user or administrator experience until a security policy is explicitly enabled. The sHype port consists of three patches (tested on the xeno-unstable.bk version from March 29 th): 1. shype_4_xeno-unstable.bk_v0.2_xen.diff .. patch that includes the security enforcement code and access control module, the heart of shype; 2. shype_4_xeno-unstable.bk_v0.2_sparse.diff .. kernel patch that includes an additional /proc/xen/policycmd interface using a new policy hypercall to communicate policies between xen and the policy management tool; 3. shype_4_xeno-unstable.bk_v0.2_tools.diff .. tools patch that includes support for a new parameter security subject identifier reference (ssidref) in the domain configuration, as well as a v-e-r-y simple policy tool to set binary policies in xen and to retrieve and dump enforced policies from xen (tools/policytool); in a future version, this tool will read user-defined policies and compile them into the binary policies to be downloaded into xen. If you install the patches, please start with a clean xeno-unstable.bk tree: make mrproper; make uninstall; >patch the code here<; make; ./install.sh. More instructions to follow. Comments/feedback related to these patches are very welcome. Note that I will not be able to read my email from April 1st to 11th. If anyone has any quick questions I will try to answer them before I leave; otherwise, please look through the code at your convenience and let us discuss details once I am back. (Note that the code is still "under development" -- for example, work continues on save/restore support & on revoking resources to enable policy changes at run-time, as well as moving the enforced policy from a hard-coded parameter to a compile-time option). Kindest Regards Reiner Signed-off-by: Reiner Sailer __________________________________________________________ Reiner Sailer, Research Staff Member, Secure Systems Department IBM T J Watson Research Ctr, 19 Skyline Drive, Hawthorne NY 10532 Phone: 914 784 6280 (t/l 863) Fax: 914 784 6205, sailer@us.ibm.com http://www.research.ibm.com/people/s/sailer/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Reiner Sailer wrote:> Comments/feedback related to these patches are very welcome.+++ xeno-unstable.bk/tools/policy/policy_tool.c 2005-03-29 ... +int acm_domain_set_chwallpolicy(void *bufstart, int buflen) { +#define CWALL_MAX_SSIDREFS 5 +#define CWALL_MAX_TYPES 10 +#define CWALL_MAX_CONFLICTSETS 2 +int acm_domain_set_stepolicy(void *bufstart, int buflen) { +#define STE_MAX_SSIDREFS 5 +#define STE_MAX_TYPES 5 +++ xeno-unstable.bk/tools/python/xen/lowlevel/xc/xc.c 2005-03-29 ... + u32 ssidref=5; +++ xeno-unstable.bk/tools/python/xen/xm/create.py 2005-03-29 ... +gopts.var(''ssidref'', val=''SSIDREF'', + fn=set_int, default=05, + use="Security Identifier.") What are all these magic numbers (5, 10, etc.)? -- David Hopwood <david.nospam.hopwood@blueyonder.co.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel