Dear Xen community,
prior to the Xen summit in Cambridge there was a second meeting on
security enhancements for Xen. This time a wider audience was present
as various parties expressed interest after the initial meeting in
Boston. Below is a short report of what was discussed and decided at
the meeting; my apologies in the delay in circulating this which is
due an excess of travel and other committments.
For those of you wishing an executive summary:
- broad agreement on the direction to take in order to build a
security enhanced version of Xen ("XenSE")
- timescale is generally post 3.0 although some initial changes
will be made prior to 3.0
- a new mailing list xense-devel@xxxxxxxxxxxxxxxxxxx has been
created to which interested parties should subscribe.
best,
Steven.
--------------------------------------------------------------------------
Xen Security Meeting
13:30--17:30 BST, Tuesday 5th April 2005.
Intel conference room, Intel Research Cambridge, CB3 0FD, UK.
Attendees:
Will Burton (CESG/HP Labs)
Joe Cihula (Intel)
Christopher Clark (U. Cambridge)
George Coker (NSA)
Chris Dalton (HP Labs Bristol)
Steve Hand (U. Cambridge/XenSource)
Dirk Kuhlmann (HP Labs Bristol)
Markus Kuhn (U. Cambridge)
Jonathan Lawrence (CESG)
Peter A. Loscocco (NSA)
Rolf Neugebauer (Intel Research Cambridge)
Carlos V Rozas (Intel)
Vin Scarlata (Intel)
Geoffrey Strongin (AMD)
Leendert Van Doorn (IBM Research)
Robert Watson (McAfee)
Andrew Warfield (U. Cambridge)
Mark Williamson (U. Cambridge)
Agenda:
0. Introductions + administivia (mailing list, source repository, ..)
1. MAC in Xen:
- interface for pushing policy
- caching access checks
- security manager location + interface
2. TPM support
- trusted boot
- TPM virtualization
3. Minimizing the TCB
- refactoring dom0
- resource containment
- more general narrowing/tightening of dom<->xen privilege
4. Devices and device security
- platform support
- securing the I/O path
- performance and scheduling
5. Close
0. Administrativa
-----------------
- Mailing list: should security related discussions be held on xen-devel
or should a separate mailing list be created? Most folks were in favour
of a separate mailing list as that way people can more easily filter out
the "noise" on xen-devel. Mailing list archives should be public but
there was some discussion on whether the membership should be restricted
to keep the noise down.
DECISION: the list should be open to all in addition to having
publicly accessible archives.
ACTION: Steve to set up a security related mailing list on
XenSource's list server and subscribe all attendees.
- Source code repository: should there be a separate source code
repository for security related work or should we try to keep it in
xen-unstable? The idea for a separate repository is that it could track
the main development tree closely but would allow easier/earlier distribution
of patches while decoupling the security related development from the
normal xen release cycle (especially the 3.0 release). Leendert expressed
a strong preference for trying hard to keep security related patches in
the main development tree and only to fork off when necessary.
DECISION: XenSE work will take place in the mainstream unstable tree
until such time as major and/or API incompatible changes
are required.
1. Mandatory Access Control
---------------------------
Leendert kicked this part of the meeting off with a brief description
of the MAC patches sent by Reiner Sailer to the xen-devel mailing
list. These patches essentially provide LSM style hooks for most of
the xen interface, in particular the event-channel and grant-table
mechanisms.
ACTION: IBM to submit updated patches to xen-devel for review and
hopefully inclusion in unstable.
UPDATE: Reiner did this; Steve is currently investigating how best
to integrate this functionality into the tree.
The basic idea is to provide access checks at bind time with a
revocation mechanisms to reduce the performance impact of MAC
checks. The supplied patch, which IBM has brought forward for
discussion, allows multiple policies to be implemented and to provide
high assurance between groups of VMs but to provide finer grained but
less assurance within these groups.
Pete raised the concern that Dom0 also needs to be taken into account (a
topic covered more in detail later in the meeting). Leendert suggested
that specialised library OSes should be used for some of the security
related functions.
Pete pointed out that a lot of thought went into the interfaces of the
FLASK architecture and that some of these are not in LSM. He suggested
to seriously consider the adoption of these interfaces rather than LSM
style ones. Key aspects are whether or not policies are stateful, and
whether or not an explicit security server is present.
Pete pointed out that for MAC a thorough analysis needs to be made on
what the first class objects are and how these are access in order to
place the access hooks. Leendert pointed out that that is what IBM has
done and based the MAC patches on. Pete mentioned that they will do
their own analysis.
A final point made by Pete was that the aim should not just be to make
Xen more secure but to make the platform more secure. As part of this
platform MAC has to include services outside Xen (for robustness), ie a
security service running in its own VM might provide it's own access
control policies. However, it might be useful/necessary for these
services to have access to resources used by Xen (such as labels) for
its MAC. Another point which came up in the discussion was that one
might also want to define a virtual platform formed from groups of VMs,
each of which with their own set of services. Furthermore, it is
desirable to allow guests to provide finer grained MAC on their own
(e.g. by using SELinux), something Leendert alluded to earlier on.
Leendert continued with describing their current work in progress. With
the current patcht-set the MAC policy server resides in Xen but that
they have a just made working a version where the policy server resides
in a VM with an access cache in Xen. Pete supported this architecture in
that it is important for isolation.
The general agreement on the MAC topic was that all participant were
roughly on the same wavelength on how MAC should be provided for Xen and
that the IBM patches are a good basis for continued discussion on the
mailing list
ACTION: Pete+Leendert+Carlos to produce a diagram illustrating the various
options for the place of the security manager, policy etc
2. TPM support
--------------
Two topics where discussed:
- Hardware TPM support and measurement
- virtual TPM
For bootstrap core TCG measurements and hardware TPMs should be used.
This is just for bootstrap and static measurements (i.e. for Xen and
service OSes etc). However the general consensus was that we should
move to something more flexible for full blown guests as these are a)
hard to measure due to their complexity and b) also require continuous
runtime measurements. For this a software solution is required.
Likewise a software solution is required for virtualising the TPM, since
the hardware TPM needs to be exposed in some way to the guest. Both IBM
and Intel reported that they are working on virtual TPM systems.
Leendert described their initial prototype which uses a full software
1.2 TPM implementation and exports a virtual TPM interface to other
guests via backend/frontend drivers. The hardware TPM is only used for
attestation of the software TPM implementation.
Carlos reported on a similar but more generalized effort. In particular
the idea is to use TPM h/w to bootstrap a minimal "security service"
which provides TPM-like functionality which can then be exported to
various guest domains, etc. By exposing a separate, hardware
independent interface to guests you allow innovation and a variety
of hardware/software hybrid implementations.
Both parties want to release their code to the community but there
were some uncertainties whether the TCG allows the general source code
release of full software TPM implementations. In this context it was
also pointed out that a generally available software implementation
would be very useful for research purposes.
ACTION: Leendert + Carlos to discuss and then inform the list what
code will be released and when.
Rolf reported that he & Gregor Milos are working on a prototype
implementation of basic TPM and measurement support for Xen. This
effort also involves restructuring the domain building process in
order to facilitate static measurements.
Geoffrey recognized that there are a number of limitations of today's
TPMs. In particular, trying to determine what it /means/ to talk
about attestation in a server (e.g. utility computing) environment
is not very well defined.
3. Reducing the TCB: Refactoring Dom0
-------------------------------------
Currently the TCB consist of Xen + dom0 + driver domains, violating the
principle of least privilege. In particular the functionality performed
by Dom0 requires splitting up into smaller units.
Various people expressed the need for "lightweight domains" (smaller
than Linux) in order to implement security services or service
OSes. These should provide a multithreaded environment with a libc
like API. It should be possible to prototype services in Linux (for
ease of debugging) and then transfer the service into a more
lightweight OS.
Steve pointed out that such a lightweight OS should be reasonably
straightforward to implement, but it was agreed generally that this
was not the highest priority for now. Rather the more important task
was to investigate the various Xen interfaces (hypercalls, dom0_ops,
shared data/events) and tidy them up where necessary.
As part of this activity a functional analysis of Dom0 is required. It
was agreed that this should be done per email discussion.
ACTION: (all) analysis of dom <-> xen interface to be carried out
via public mailing list, etc. Outputs should be a list of
abstract functions which are provided by this interface
(which includes regular hypercalls, 'dom0_ops' and the
various shared data structures); the dependencies between
these; and an initial assessment of risks.
Pete also pointed out that the deconstruction could be done in two
ways, either by restructuring dom0 itself into functional units and
use MAC with dom0 or to split up Dom0 functionality into separate xen
objects (viz VMs) and perform MAC on the Xen level. He reckoned that
probably a combination of both will be needed.
4. Devices and Device Security
------------------------------
Both AMD and Intel reported that they have 'some' hardware support
for dealing with untrusted device drivers / devices. Fairly low-level
mechanisms somewhat focused on 'trusted path' (and so e.g. deal with
HIDs such as mouse + keyboard). There was also a discussion about the
level of support for secure/trusted graphics, but it was not possible
for any details to be disclosed publicly at this time by or to any of
the parties .
It was hoped that many of the technical details of Presidio and LT
etc would be available publicly soon to facilitate further discussion
of this topic.
We also spoke briefly about resource metering; given that this is a
general aim of Xen in any case it was decided this wasn't a specifically
XenSE-related topic.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home