Xen devel - Jan 2005 - sHype Hypervisor Security Architecture for Xen

I am a member of the Secure Systems Department at IBM''s TJ Watson
Research
Center (http://www.research.ibm.com/secure_systems_department/). 

Our group has designed and developed a security architecture for 
hypervisors (called sHype). We have implemented it on an x86-based IBM 
research hypervisor.  We now plan to contribute this to Xen by integrating 
our security architecture into it. 

sHype is based on mandatory access controls (MAC). This allows Xen to use 
access rules (formal policy) to control both the sharing of virtual 
resources as well as the information flow between domains. The Xen port of 
sHype will leverage the existing Xen interdomain communication mechanism 
and we expect near-zero performance overhead on the performance-critical 
paths (e.g., sending or receiving packets on a virtual network, or writing 
or reading shared memory).  The sHype access control architecture 
separates policy decisions from policy enforcement. It is modeled after 
the Flask security architecture as implemented in SELinux (
http://www.cs.utah.edu/flux/fluke/html/flask.html).  Our design is 
targeted at a flexible medium-assurance architecture that can support 
anything from simple security domains to multilevel security (MLS) and 
Chinese Wall policies. 

Merging the sHype access control architecture with Xen is the first step 
toward our goal of hardening Xen to support enterprise-class applications 
and security requirements. We are working on the following items to 
achieve this goal (which we intend to contribute spread out over this 
year):

* Port sHype to Xen 

* Add stronger security/isolation guarantees (confinement) to what is 
currently available through Xen''s (and other hypervisors'')
address space
separation mechanisms, e.g., to enable information flow control in Xen 

*  Enhance Xen to support trusted computing under Linux using 
TCG/TPM-based attestation mechanisms 

*  Enhance Xen to support secure resource metering, verification, and 
control. 

* Apply our experience in automated security analysis to Xen to make it 
more robust 

* Make Xen suitable for Common Criteria evaluation 

We are confident that our work will significantly contribute to Xen in the 
security space and that it is a good fit with the Xen roadmap. We look 
forward to interacting with the Xen community on the design and 
implementation of our architecture.

Reiner
__________________________________________________________
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/

There is some work going on in this area in Intel Research, although so far we 
mostly identified problems rather then came up with a solution. In any case 
cooperation in enhancing the security of Xen would certainly be better then 
separate efforts.
I will be most interested to learn the details of sHype and then trying to 
find the way to port it to Xen.
I can be contacted directly on gm281@cam.ac.uk.

Cheers
Gregor
> I am a member of the Secure Systems Department at IBM''s TJ Watson
Research
> Center (http://www.research.ibm.com/secure_systems_department/).
>
> Our group has designed and developed a security architecture for
> hypervisors (called sHype). We have implemented it on an x86-based IBM
> research hypervisor.  We now plan to contribute this to Xen by integrating
> our security architecture into it.
>
> sHype is based on mandatory access controls (MAC). This allows Xen to use
> access rules (formal policy) to control both the sharing of virtual
> resources as well as the information flow between domains. The Xen port of
> sHype will leverage the existing Xen interdomain communication mechanism
> and we expect near-zero performance overhead on the performance-critical
> paths (e.g., sending or receiving packets on a virtual network, or writing
> or reading shared memory).  The sHype access control architecture
> separates policy decisions from policy enforcement. It is modeled after
> the Flask security architecture as implemented in SELinux (
> http://www.cs.utah.edu/flux/fluke/html/flask.html).  Our design is
> targeted at a flexible medium-assurance architecture that can support
> anything from simple security domains to multilevel security (MLS) and
> Chinese Wall policies.
>
> Merging the sHype access control architecture with Xen is the first step
> toward our goal of hardening Xen to support enterprise-class applications
> and security requirements. We are working on the following items to
> achieve this goal (which we intend to contribute spread out over this
> year):
>
> * Port sHype to Xen
>
> * Add stronger security/isolation guarantees (confinement) to what is
> currently available through Xen''s (and other
hypervisors'') address space
> separation mechanisms, e.g., to enable information flow control in Xen
>
> *  Enhance Xen to support trusted computing under Linux using
> TCG/TPM-based attestation mechanisms
>
> *  Enhance Xen to support secure resource metering, verification, and
> control.
>
> * Apply our experience in automated security analysis to Xen to make it
> more robust
>
> * Make Xen suitable for Common Criteria evaluation
>
> We are confident that our work will significantly contribute to Xen in the
> security space and that it is a good fit with the Xen roadmap. We look
> forward to interacting with the Xen community on the design and
> implementation of our architecture.
>
> Reiner
> __________________________________________________________
> 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/
-- 
Quidquid latine dictum sit, altum viditur --- Anon


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Sun, 16 Jan 2005 18:41:12 -0500, Reiner Sailer <sailer@us.ibm.com>
wrote:
>  
> I am a member of the Secure Systems Department at IBM''s TJ Watson
Research
> Center (http://www.research.ibm.com/secure_systems_department/). 
>  
> Our group has designed and developed a security architecture for
hypervisors
> (called sHype). We have implemented it on an x86-based IBM research
> hypervisor.  We now plan to contribute this to Xen by integrating our
> security architecture into it. 
this project looks interesting. do you have a discussion mailing-list
for the project?

best regards,
AQ


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

aq <aquynh@gmail.com> wrote on 01/16/2005 09:51:16 PM:
> On Sun, 16 Jan 2005 18:41:12 -0500, Reiner Sailer <sailer@us.ibm.com>
wrote:
> > 
> > I am a member of the Secure Systems Department at IBM''s TJ
Watson
Research
> > Center (http://www.research.ibm.com/secure_systems_department/). 
> > 
> > Our group has designed and developed a security architecture for 
hypervisors
> > (called sHype). We have implemented it on an x86-based IBM research
> > hypervisor.  We now plan to contribute this to Xen by integrating our
> > security architecture into it. 
> 
> this project looks interesting. do you have a discussion mailing-list
> for the project?
> 
> best regards,
> AQ
We don''t have a separate public mailing list for sHype. We would 
like to start discussing sHype on the Xen development mailing list.
Once this becomes very specific, we can establish a separate
mailing list for security-related topics for Xen.

Reiner

> Our group has designed and developed a security architecture for 
> hypervisors (called sHype). We have implemented it on an x86-based IBM 
> research hypervisor.  We now plan to contribute this to Xen by integrating 
> our security architecture into it. 
It''ll be great to have IBM contributing to Xen security.

There''s a group in Cambridge that has been putting quite a bit of
thought into how to implement multilevel secure systems using
Xen, so I''m sure there are some interesting discussions ahead...

Best,
Ian


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Are there likely to be any publically available white papers, etc. on the 
sHype architecture any time soon?  From the website, sHype looks very 
interesting but it''s somewhat light on specifics ;-)

Cheers
Mark


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Mon, 17 Jan 2005, Reiner Sailer wrote:
> We don''t have a separate public mailing list for sHype. We would
> like to start discussing sHype on the Xen development mailing list.
> Once this becomes very specific, we can establish a separate
> mailing list for security-related topics for Xen.
I agree with this approach.  Since the goal is to merge the
technology into Xen, the discussion really should be held in
a place where the Xen developers can participate easily.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Has anyone from the Xen community been following the
development of the draft "U.S. Government Protection
Profile for Separation Kernels in Environments
Requiring High Robustness", which has lately been
discussed at Open Group?

http://www.niap.nist.gov/pp/draft_pps/pp_draft_skpp_hr_v0.621.html

The concept of a separation kernel in that protection
profile has a fair amount of overlap with Xen,
although the match is not complete (i.e. configuration
data is static in the SKPP). Still, the PP has some
interesting xen-relevant bits if you''re willing to
wade through the boilerplate that permeates protection
profiles. In any case, while I doubt Xen will ever
pursue Common Criteria evaluation under this profile,
the security-concious portion of the Xen community
might get something out of reading it.

Regards,

Jeff Marshall
jeffrey_g_marshall@yahoo.com



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

xen-devel-admin@lists.sourceforge.net wrote on 01/17/2005 02:43:06 PM:
> Are there likely to be any publically available white papers, etc. on 
the 
> sHype architecture any time soon?  From the website, sHype looks very 
> interesting but it''s somewhat light on specifics ;-)
> 
> Cheers
> Mark
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It''s fun and FREE -- well,
almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel

we are currently working on an sHype white paper and the clearing process 
for its publication is ongoing. We will publish it on this mailing list as 
soon as it 
is available  and cleared.

In the meanwhile I will pull together some notes that I can submit to the 
mailing list
this week, so that we can get the discussion started in a meaningful way.

Regards
Reiner

Jeff Marshall <jeffrey_g_marshall <at> yahoo.com> writes:
> 
> Has anyone from the Xen community been following the
> development of the draft "U.S. Government Protection
> Profile for Separation Kernels in Environments
> Requiring High Robustness", which has lately been
> discussed at Open Group?
> 
> http://www.niap.nist.gov/pp/draft_pps/pp_draft_skpp_hr_v0.621.html
> 
> The concept of a separation kernel in that protection
> profile has a fair amount of overlap with Xen,
> although the match is not complete (i.e. configuration
> data is static in the SKPP). Still, the PP has some
> interesting xen-relevant bits if you''re willing to
> wade through the boilerplate that permeates protection
> profiles. In any case, while I doubt Xen will ever
> pursue Common Criteria evaluation under this profile,
> the security-concious portion of the Xen community
> might get something out of reading it.
> 
> Regards,
> 
> Jeff Marshall
> jeffrey_g_marshall <at> yahoo.com
> 
Jeff,

We haven''t necessarily been "following" this PP, but we are
quite aware of it. I
would also add that SKPP seems to be designed (by NSA and others) in part to
support their MILS (Multiple Independent Levels of Security) "separation
kernel"
concept. So, what is MILS? It''s essentially the disaggregation of
system
security into manageable components that can be evaluated separately -- e.g.,
secure service partitions. Here''s a couple of other descriptions from
NSA:

"Instead of placing all security requirements in this security kernel we
want to
share the responsibility for security with the application layer.  In the old
Orange Book, i.e., TCSEC, the definition of Reference Monitor was: non
bypassable, always invoked, tamperproof, and evaluatable.  What we want to be
able to do is to create a layered reference monitor architecture.  The
responsibility of this security kernel or separation kernel is to enable the
middleware and application layer entities to security manage, control, and
enforce their own security policies.  We want an architecture that allows the
security kernel to share the responsibility of security with the
application."

"The MILS architecture was developed to resolve the difficulty of
certification
of MLS systems, by separating out the security mechanisms and concerns into
manageable components. A MILS system isolates processes into partitions, which
define a collection of data objects, code and system resources. These individual
partitions can be evaluated separately, if the MILS architecture is implemented
correctly. This divide and conquer approach will exponentially reduce the proof
effort for secure systems. To support these partitions the MILS architecture is
divided into three layers: Partitioner, Middleware Services, and
Applications."

Note however that SKPP is targeting fairly high levels of assurance (EAL6+).
While sHype does address the same/similar concepts as those addressed in SKPP,
achieving that level of assurance would be quite a challenge for anyone (IMHO).

Regards,
-Ron

Ronald Perez
Manager, Secure Systems
IBM Thomas J. Watson Research Center, Hawthorne, NY




-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

xen-devel-admin@lists.sourceforge.net wrote on 01/20/2005 08:32:58 PM:
> Mark Williamson wrote:
> >>Information about other domains'' memory usage is leaked
via the
> >>hardware->physical mapping.
> > 
> > OK, I was forgetting about the domain memory reservation hypercalls. 
It''s 
> > probably reasonable just to throw away ballooning functionality where 
this 
> > might be a problem.
> > 
> > The main problem (as I see it) is going to be the network interface, 
whose 
> > performance depends on page-flipping.  You can eliminate the 
> security problem 
> > without hiding machine address if you copy incoming packets but 
> that''s going 
> > to hurt performance :-(
> > 
> >>>Timing related attacks are somewhat trickier to eliminate
covert
channels
> >>>in, although some randomisation can limit the bandwidth.
> >>
> >>Eliminating covert channels is completely infeasible. I
don''t see any
> >>value in aiming for this. It''s not a useful security
property in most
> >>circumstances.
> > 
> > I agree it''s not useful in the majority of circumstances.  If
it''s
> required it 
> > can be implemented at a later date but the returns for the amount of 
time 
> > invested are likely to be smaller.
> 
> It almost certainly can''t be implemented at a later date. Even 
attempting
> to do so (without really succeeding) would require significant 
incompatible
> changes to the hypervisor interface.
> 
> The idea of limiting covert channels should have been abandoned when it
> became clear that it isn''t feasible without severely constraining
the
> efficiency and functionality of an operating system. Unfortunately it is
> too interesting a problem, so a lot of effort has been essentially 
wasted
> in research into this area, without ever coming up with any way to limit
> the bandwidth to a useful extent. Attackers only need a very small
> bandwidth to transmit many of the things that are most useful from their
> point of view (cryptographic keys, passwords, compressed answers from a
> program that can look at any amount of data), so claims about limiting 
the
> bandwidth really just give a false sense of security.
> 
> -- 
> David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
> 
> 
Hello,

it is quite understandable that many people are sceptical regarding covert
channels. But as Trent mentioned, we are not currently aiming to address 
covert 
channels.  They are difficult to detect, difficult to assess, and 
sometimes very 
difficult  to close. Worst of all, no matter how hard you work, you''re 
never done 
(at least you never know).

Of course, all security-relevant properties of a system, including covert 
channels, 
are relevant to the context of the security architecture.  But as others 
have said in this 
discussion, there are more important points to discuss about the security 
model for Xen.

What we have implemented is a security architecture that integrates a 
reference 
monitor into a core hypervisor. The expected usage is to create 
"associated sets" 
of partitions, where partitions inside the same set can efficiently 
cooperate
by using the existing inter-partition communication mechanisms. At the 
same 
time, partitions not inside the same set -- i.e., each having different 
security 
requirements -- shall be strongly isolated from each other by the 
hypervisor.

Accordingly, the flow of information between partitions belonging to
different "security domains" must be explicitly mediated to prevent 
leakage of information (this is an important issue from a secrecy 
viewpoint) or to prevent spreading of malicious code (this is an 
important issue from any viewpoint because integrity is a basis 
for secrecy as well).  We are targeting the hypervisor to enforce the
security policy because the extensive DOM0 seems too large to validate.

In summary, we are interested in minimizing covert channels only 
as a consequence of the overall security architecture. Our major interest 
for now is to describe our baseline security architecture and then work
out the details and configurations that seem reasonable to the Xen 
community.

Kindest regards

Reiner
__________________________________________________________
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/