[Xen-devel] Xen Security meeting summary

["Neugebauer, Rolf" <rolf.neugebauer@xxxxxxxxx>]

We had a Xen/Security meeting at Linuxworld in Boston. Below is a
summary of the topics/discussion.
Rolf


Xen security meeting at LinuxWorld Thursday 17/02/05
----------------------------------------------------

The purpose of this initial meeting was to discuss various
additions/changes to Xen to create an open-source, high-performance,
secure VMM. It was initiated by some security researchers who
expressed interest to meet with the Xen team to discuss Xen/Security
issue. As such the meeting was primarily focused on Xen specific
issues rather than general security architecture issues. We plan to
have further meetings with the next one likely to coincide with the
Xen summit in Cambridge beginning of April.

Present:
- Keir Fraser, Christian Limpach (University of Cambridge, XenSource)
- Mona Vij, Carlos Rozas, Anand Rajan (Intel CTG)
- Joseph Cihula, Asit Mallick (Intel SSG)
- Leendert van Doorn (IBM Research)
- Rolf Neugebauer (Intel Research Cambridge)


Scope/usage model:
------------------ 
Leendert suggested to focus on fairly simple usage models akin to the
PR/SM system but keep in mind more advanced models in the process of
designing. As an working example he suggested a consolidated server
hosting VMs for different (competing) customers and use TCG derived
methods to assure customers of the secure isolation of their
service. Such a usage model would offer only limited sharing of
resources but we should keep more finer grained sharing in mind.

Everyone agreed that this was a sensible approach given the current
server orientation of Xen. At a later stage the security architecture
should also be extended to client systems.

Mandatory Access Control
------------------------
As adding MAC to Xen would initially require the most pervasive
changes to Xen the meetings main focus was on this topic. Everyone
agreed that the addition of MAC should not impact the overall
performance of Xen as this is one of its main advantages. Leendert
also expressed his believe that security should be always on,
i.e. should not be made optional.

Leendert detailed their addition of MAC to the IBM rHype research VMM
as described in the recently posted sHype paper. sHype performs MAC at
resource binding time and provides a revocation mechanism to revoke
access to a resource. This avoids the cost of access checks on every
resource access. To everyone present this seems like a sensible
approach to adapt for Xen.

Following was a discussion on the various shared resources in Xen for
which MAC would have to be performed, focusing in particular on event
channels and page sharing. In Xen, these primitives are used to
provide higher level abstractions such as virtual devices. In sHype,
higher level abstractions, such as virtual NICs are provided by the
hypervisor. After a brief description of these primitives and their
use it was thought that providing MAC at this (lower) level could be
used to provide similar functionality to sHype, which provides virtual
devices directly to VMs.

As event channels require an explicit binding to end-points, there
already exits a natural point for performing MAC. Adding a check for
revocation of access should be straightforward and shouldn't impact
performance.

The grant-table design for page sharing also provides natural check
for MAC, however, revocation requires a little more thought,
especially its interaction with writable page-tables. However, as Keir
pointed out, if revocation is rare a relatively slow approach to
revocation (scanning all guest page tables) would be acceptable. If
this proves to be too slow, additional bookkeeping information could
be used to speed up revocation.

Intel noted that providing MAC on the privileged operations of Domain
0 and other hypercalls is also necessary but it was agreed that this
requires closer inspection. It was indicated that the Xen team is open
to changes to some of these interfaces should that be necessary from a
security point of view, especially the dom0 interface is far from cast
in stone. A detailed discussion of these issues was deferred to a
later meeting: first some initial implementation work on MAC should be
done.

MAC also requires the introduction on an access control module into
Xen with appropriated interfaces to push policies into Xen from within
a VM. Intel noted that the access control module could be hosted in
user space and that a simpler access vector cache could be maintained
in Xen along the lines of the Flask architecture. There are various
ways of doing this (shared memory, hyper-calls) and the dom0 interface
could be used as an example. The access control module might also
require the ability to call back into the security manager VM
depending on the implementation. This mechanism can be provided on top
of events. It was discussed to initially use a simple policy, such as
Chinese Wall, to gain some experience with implementing this interface
in Xen. The Xen team is open to suggestion as to what the interface
should look like and that it shouldn't be a problem to add such an
interface to Xen.

The final item under the MAC subject was that of resource
naming/labeling. This issue was only briefly discussed. Leendert
suggested that the use of certificates might be more appropriate than
labels. It was also flagged that it requires some careful
considerations in a dynamic system. Apparently more fun can be had
when considering VM migration.



Reducing the TCB
----------------

An issue that came up multiple times was that of reducing the TCB.

- Currently, dom0 is too privileged and its functionality needs to be
either cut down and/or carved up into smaller pieces. We deferred a
more detail discussion on this subject to a later meeting. This is
also to involve the possible restructuring of dom0_ops and the way
domains are built.

- The current toolset (xend) was also mentioned as a possible problem
area. However as there is a general desire to redesign them, and
possibly have multiple different implementation, this was not
discussed further.

- The use of device driver domains was briefly discussed. They
currently required higher privileges can be removed once the
grant-table design is implemented. However, without hardware support
(ie IO MMU), their capability of setting up arbitrary DMA operations
might require having smaller, specialized device driver domains (ie
not full Linux systems) which can be audited better.

- we also discussed the use of a small system controller (domain -1?)
to kick off the system as a measure to reduce the TCB.

- It was also pointed out that the planned removal of the platform
initialization code from Xen will significantly reduce the size of
Xen, but will add more privileged operations to domain 0.



Other Xen issues
----------------

- grant-tables: these should be implemented as soon as possible by the
Xen team. Not only are they necessary to reduce the privileges of
device driver domains (currently a device driver domain has to be
privileged in order to map a clients pages), but they are necessary
for MAC as well (and to use full shadow mode with para-virt device
drivers). The implementation should also include a revocation method
in order to implement sHype style MAC.

- page mapping visibility: several people said that they felt
uncomfortable with the global visibility of mappings from machine to
physical address in a guest as this provides a lot of information to
an attacker.

- VLANs: we need to investigate how to setup/provide clearly separated
VLANs under Xen as the current default setup uses a bridge running in
the network device driver domain. Its is possible that the current
implementation can be configured appropriately. Possible alternatives
were being able to setup point to point links between two VMs etc,
also an issue might be tool support for configuring them
appropriately.


Covert Channels
---------------

We had a brief discussion on covert channels and in the end decided
not to address them as a complete elimination of covert channels would
be prohibitively expensive (if at all possible). However, we should
look at possible covert channels and eliminate them were they are easy
to fix. For other covert channel we need to identify them and assess
their bandwidth. Leendert suggested to not make covert channels an
immediate high priority, to to focus on other issues first.

On this subject, we discussed the globally visible page mapping (see
above). As the Xen team is currently also implementing a full shadow
mode, this problem might go away, depending on the performance impact
of shadow mode vs writable pagetables as used at the moment. The Xen
team will provide a performance evaluation of the different modes.

Resource Control
----------------

We briefly discussed resource control, not primarily a security issue,
but an issue of robustness and useful as a first line defense against
DOS attacks. Since one of Xen's main aims is to provide resource
isolated execution of VMs it was noted that the goals here are in
common. However, Xen might need to provide better resource metering
and might also need changes to the tool-set to easier set up things
like network bandwidth limiters etc.


Measurement/Attestation/TPM
---------------------------

Again we only briefly touched on this subject. While it would be
desirable to provide attestation from BIOS to applications, we decided
that for TPM enabling we should do small steps and build from
there. In an initial attempt we would only support attestation up to
the hypervisor level. Intel will initially be investigating what needs
to be measured within the hypervisor and how (command line args
etc). 

Both Intel and IBM are looking at TCG enablement. IBM has a virtual
1.2 TPM solution working with on Xen and Intel is in the process of
porting their implementation to Xen.

We also briefly talked about research into dynamic (ie runtime)
measurements.

Another research topic, briefly discussed, is the impact of migration
on attestation, probably best addressed within the TCG.



Assurance
---------

We briefly discussed whether and what assurance level should be aimed
for. It was agreed that EAL5 would be really hard to achieve (but
might be possible). EAL4 should be possible.  However, since any
official certification requires significant effort (and investment)
this is primarily a business decision which should be made
later. However, it was expressed that we should keep in mind possible
certification, ie keep a particular protection profile in mind when
setting requirements, have code/design reviews. Leendert also pointed
out that we should make sure that the Xen code passes IBMs source code
analysis tools.



Administrativa
--------------

- we will set up a public mailing list for security/xen issues as soon
as the proposed move of xen-devel has been done.

- we'll use the xen summit in April to have the next meeting

- Keir pointed out that the best way of integrating code into Xen is
to supply patches early, but have new features disabled by default.


Activities
----------
Here is a brief list of what the various attendees will be working on:

IBM:       - MAC, try to provide some initial code in soon
           - TCG enablement + assurance
Intel:     - Measurement/Assurance
Cambridge: - fix grant-table
           - revocation mechanism for grants/event channels
           - assist with integration of code
           - set up xen security mailing list
All:       - reducing TCB, restructuring of Dom0



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel