Re: [Xense-devel] Labeling resources

[Reiner Sailer <sailer@xxxxxxxxxx>]

Hi David,

Congratulations to your son! I wish
you and your family all the best and an exciting time.

David Palmer <dwpalmer.xense@xxxxxxxxx> wrote
on 09/22/2005 02:25:15 PM:

> I've been out for a couple weeks helping my wife
with our newborn 
> son.  It's been great learning about sleep
deprivation and what it 
> means to be a father.  Please bear with
me as I try to get my brain 
> unclouded and put together intelligible sentences
and coherent paragraphs.
>
> I think we'd agree that the basic premise to
mandatory access 
> control (MAC) is that if subject X wants to access
object Y, then a 
> trusted third party, subject Z, must be consulted
to grant or deny 
> the access.  Otherwise, if Y is a subject
that makes the decision 
> for itself, then we have discretionary access
control (DAC).  This 
> latter method is known to be ineffective and
is why MAC is used 
> instead.  If we do not agree on this, please
let me know.

We agree.

We do believe that we need finer-grained
access control exported by the VMM. However, we are experimenting with
splitting the implementation into "in-hypervisor" and "in-trusted-domains"
parts for Xen (because of the Xen hypervisor structure).

My personal opinion is that the simple
type enforcement alone, currently implemented in the Xen hypervisor, is
insufficient on application level. There must be OS support as well. I
am convinced that using a simple policy in the hypervisor will allow stronger
security guarantees of a (very) coarse-grained kind but nevertheless very
valuable (if low overhead). I hope that XenSE (the whole) will pull the
pieces together into a coherent project that allows flexible refinement
on higher levels where required ("pay" if and where you need
security).

> So, what I see is that the dom_Network may try
to access 
> dom_Storage.  For this to happen, a third
party, say the hypervisor,
> must decide whether this access is allowed.  Once
this basic 
> connection is allowed, then we introduce partition
objects.  For 
> dom_Network to access a partition, dom_Storage
is consulted to 
> decide whether the access is allowed.  In
this manor, we 
> consistently provide MAC without regressing to
DAC.  How dom_Storage
> wants to manage its resources and provide MAC
is up to dom_Storage. 
> That's fine, though it may be nice if it could
use and extend the 
> existing hypervisor based MAC if it is found
to be adequate.

If I follow you, then you would like
to minimize the trust we put into dom_storage. The trade-off seems to be
a) by-design: minimize dom_storage (don't
compile a net-frontend into it; dom_storage is not a user domain, it is
part of the VMM and fully controlled; if it stops doing what it is designed
to do, then we are in "TCB-trouble" anyway)
b) by-acm-policy: restrict dom_storage
properties through the hypervisor

We are currently betting on a), i.e.,
we are betting on de-aggregation of Dom0 which we consider necessary in
any case to achieve acceptably small TCB size. Discussions are good and
valuable here also on xen-devel.

I am currently working on your suggested
additional ACM call that allows a (dom_storage) domain to ask the hypervisor
ACM for a policy decision regarding a domain trying to access a virtualized
resource (vdisk) based on various information (e.g., domid, vdisk ssidref).
This should simplify experiments.

The overall goal is to layer the policies
and the enforcement. If one layer breaks, then there is still another (independent)
layer to go through. Hopefully (sigh ...) the enforcement becomes more
reliable when moving towards the lower layers. This hope is based on less
complexity and less exposed interfaces to exploit (might be a naive assumption).
It will become more coarse-grained when moving down the layers since we
have less and less semantics on data and operations. Getting more coarse-grained
down the stack helps to prevent from higher layer policies permitting operations
that are then denied by lower levels (as long as the higher layers work
within their policy).

POSSIBLE Xen policy layers:
1. Hypervisor: Access control independent
of domains
2. Device MAC Domains: have multiple
types and offer isolated virtual resources based on shared peripheral hardware
to multiple types (access control independent of other user domains

-- up to here very simple and VMM specific,
hopefully no perceivable overhead since "always-on" (if configured
:-) --

3. Data MAC Domains: have multiple types
and enable controlled sharing of data / information between domains (within
confinement boundaries of the hypervisor, i.e. the Data MAC domain's types)
4. User Domains: have one type (color)
and can implement MAC or DAC as required by workloads in the user domains
(they work within confinement boundaries of the hypervisor -- single color),
then it goes into middleware and application-level policies

> The hypervisor, however, provides a basic STE
policy for managing 
> connections between domains.  As a security
architect, I need the 
> ability to read the policy and make strong assertions
about the 
> security of the platform.  If I have to
read and evaluate too much 
> source code, I will fail at my job.  I rather
like the separation 
> kernel work done by John Rushby in 1981, "Design
and Verification of
> Secure Systems".  You've probably read
his papers, but I'll attach a
> couple here for those who haven't.  The
basic idea is that the 
> separation kernel only provides one security
property - separation 
> of system components.  This enables looking
at the system as a 
> collection of independent devices with dedicated
wires between them.
> Communication is only possible where wires exist.
 With this model, 
> I can consider a specific threat and reason about
what must fail in 
> order for attacks to be possible.   This
lets me focus efforts on 
> the critical components for the known threat
and not worry about 
> other components.  The security policy file
for MAC enables 
> dynamically reconfiguring the wiring for different
functional goals 
> while preserving assurances for security goals.
 It's important then
> that I can look at the policy file and reason
about what must happen
> for certain threats to be realized.  I'm
finding this difficult to 
> do with STE as defined in ACM.  Much of
this is because I only want 
> to trust the network domain with network objects,
I only want to 
> trust the storage domain with storage objects,
and I only trust the 
> hypervisor with inter-domain interactions (esp.
the wiring between 
> system components).

The hypervisor security model currently
does this kind of wiring (it's more like a bus of a color than like a point-to-point
wire). However, it shall not end at this layer. We are aiming for Xen as
a whole to provide the necessary sharing and we are experimenting with
layering as discussed above.

"The security guarantee of the
STE policy is that information can flow only within domains that share
the same color." (can be further restricted on OS-level), additionally,
by including the MAC-Domains we enable sharing of hardware resources among
different colors without breaking this assumption (but on cost of extending
the Trusted Computing Base -> minimal device domains.

Sharing of information (not hardware
devices) among two domains of different color is consequently forced to
go through a domain that has the colors of both of those domains that need
to share. To do such controlled sharing of data, the semantics of data
will likely be necessary and included in the labeling and the access control
decision and policy. Here is where MLS and finer-grained access control
policies and enforcement would come in on OS-level or higher. We hope that
the hypervisor does not need to know about semantics of data but can defer
such sharing into Multi-color sharing domains.

Specifically to your reference:
I have read the Rushby article a while
ago (the colors are inspired by one of Rushby's papers as well) and re-read
 "Design and verification of secure systems". I point to
multiple mechanisms mentioned there that are incorporated in the sHype
architecture and in its access control implementation for Xen:
 -- layering
 -- device domains (management
of shared resources in one VM is traced back by Rushby to J. P. Anderson)
-- device or data MAC domains (trusted
processes)
-- coalitions (multiple cooperating/sharing
VMs) might be compared to regimes (if regimes can subsume multiple VMs)

I believe that the wires you are talking
about and the "cutting wire" verification abstraction Rushby
is writing about relate to the event channels and the shared memory mechanisms
in Xen. Firstly, please note that while very interesting in general, verifiability
is not the major concern for our implementation; we mainly aim at commercial
environments for now (highest performance, simple and universal formal
security policy, non-intrusive to existing VMM code, medium assurance potential).
Secondly, the parts that Rushby considers not verifiable using information
flow abstractions concern the mechanisms implementing the event channels
and shared memory (those mechanisms for which the separation properties
cannot be mapped to the "flow of information" but rely on the
management of state of shared hardware / registers memory etc.); this concerns
the base Xen hypervisor, not our inter-VM access control architecture that
sits "on top" of it. Our ACM policy does not aim at controling
individual "wires" but the sharing capabilities of VM coalitions
as a whole (note: the ACM mediation hooks do control individual wires but
those don't relate back to individual policy statements).

> Using the defined STE, how do you create an effective
policy for 
> making security assurances about the system?
 Maybe showing an 
> example threat (adversarial goal) that is addressed
based on an STE 
> policy would help.  Using the example policy
provided with the XenSE
> sources would be a good starting place - what
security assurances 
> can you claim from this policy?  

This is what we will find out (usefulness).
Since we have started with a very simple policy, we have taken care that
adding more complex policies is possible and straight-forward and we encourage
it. However, this simple policy has found some friends since it is simple
and addresses most basic needs. The value of the STE hypervisor policy
is to confine failures in user domains and to control the assignment of
resources to domains (control it by formal policies rather than by ad-hoc
administrator decisions). Failures in single-typed (general) domains are
confined within one color, failures in multi-color domains (MAC domains)
are confined to the sum of their colors (figuratively speaking, when failing,
a MAC domain creates one new mixed color into which all the participating
colors flow together). Another point is to quarantine domains quickly and
strictly -- we need more work on integrating revocation into the hypervisor
hooks (here we need support for extending event-channel and grant-table
interfaces by a call-back that allows drivers to react gracefully to revocation
of their resources rather than ... help appreciated!).

> If you have to punt this to 
> resource managers (network, storage, etc), then
what value does the 
> hypervisor's STE policy have?  I agree that
the policy semantics 
> should be simple, but is it overly simplified
to where it's no longer useful?

We are working on the network and storage
device MAC domains. Since they are implementing virtual resources, they
are part of the VMM and subject to the VMM policy. Since they virtualize
disks or network, we need to trust (hopefully justified) such domains.
The separation will only be as good as the worst of these domains. However,
these domains don't have to be complex; we hope that we can interest micro-kernel
researchers and developers to contribute their expertise.

> BTW, if you have any favorite security related
papers, please post 
> references to them.  I'm always looking
for good reading material.
> 
> Dave

Some of my favorite papers: Rushby &
Randell: A distributed secure system; and J P Anderson: Computer security
technology planning study. I was able to retrieve many interesting seminal
security papers from http://seclab.cs.ucdavis.edu/projects/history/seminal.html.
However, this web site seemed a little neglected when I last visited it
(icons don't show).

Thanks and regards

Reiner
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel