Re: [Xense-devel] Labeling resources

[Reiner Sailer <sailer@xxxxxxxxxx>]

Hi David,

I finally get back to a normal working
schedule. 

xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 10/12/2005
02:05:26 PM:

> Several times I've sat down to go over your reply only to discover
> that I'm suffering from sleep deprivation.  Fortunately, today
I 
> think I was able to make some sense of the string of words though
> I'm still confused about a few points.
> 
> We seem to agree that we're not interested in this being a good 
> solution for application level security assertions.  And the
design 
> goal of "pay" if and where you need security seems reasonable.
 
> Hopefully this means we agree that this should help with system 
> level security assertions.
> 
> However, you lost me with the following:
>
> 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.
> 
> It took me a while, but by VMM I think you mean the hypervisor and
> the collection of driver domains that provide resources.  Here
are a
> few thoughts I had concerning what you're saying:

Yes. The reference monitor is in sHype/Xen represented
by the hypervisor (ACM module and hooks) and the secure subsystems that
virtualize devices outside the hypervisor (MAC domains, e.g., multi-type
driver domains).

> * Driver domains are "privileged", but I'm not clear what
the 
> privileges include and how to decide when a domain is allowed to be
> a driver domain vs. a user domain.  

Driver domains are just domains that can have multiple
STE types and have access to real hardware. The hypervisor allows such
domains to communicate with any other user VM that has one of these types.
Driver domains are a little more privileged by being allowed to call the
ACM interface to discover the STE type of the "other side" or
to retrieve access control decisions from the ACM. They also need priviledges
to directly access the hardware. They are trusted to keep their types isolated
inside their domain (there is no sharing of information inside driver domains;
just sharing of hardware).

> * I can certainly see assigning a dedicated hard disk and network
> card to a "user domain" that runs a commodity OS and forgo
resource 
> sharing and the related overhead.  Must this then be a "privileged"
> driver domain in order to access the hardware directly, and thus is
> it part of the VMM and TCB?

Driver domains that allow access to hardware only
to one type of user domains (i.e., this driver domain is single-typed)
are nothing else than a normal user domain for us. Such a domain does not
need any security privilege (it needs priviledge to access the hardware
though) and must not be trusted (from a MAC point of view).

> * You state driver domains are "fully controlled" in option
(a), but by what?
> * Certainly an exploit of a driver domain can interrupt what that
> domain was doing.  But it shouldn't be allowed to disrupt other
> domains outside their dependency upon the exploited domain.  How
is 
> that controlled if not by option (b)?

We constrain driver domains to the types they are
assigned (assigning those types is an admin procedure; using setlabel script).
All domains are subject to MAC hypervisor control and can only share (communicate)
with domains with which they share a color.

> * I don't know what an "acceptably small TCB size" actually
is 
> beyond hand waving, "we couldn't make it any smaller and still
have 
> it work."   It can still have hard to detect vulnerabilities
that 
> allow malicious code to take control of the domain.

It is certainly smaller than the current dom0. But
acceptably small means that the user is "happy" (if aware) of
the trade-off between minimal TCB and the other system parameters (non-intrusive;
off-the-shelf; inexpensive; runs anywhere; runs fast...). The sHype design
for Xen aims at offering a flexible approach.

> There doesn't appear to be any access controls for these system-
> level domains.  For how you're suggesting STE is used, all system
> level domains have access to every other domain without restriction
> by the ACM.  

The assumptions are: the hypervisor and MAC domains
form the reference monitor and are trusted. Following the principle of
least privilege, we assign types to MAC domains so that they can only share
with domains they actually serve. If they are broken, then only those types
are affected that are assigned to the broken domain. We follow the minimal
code principle by minimizing the TCB by minimizing MAC domains (well, once
they exist :_).

> This creates two problems 1) without intense
code 
> reviews, it's not clear that there aren't extra dependencies between
> those domains, and 2) if one domain is compromised, the exploit can
> use otherwise unneeded functionality to attack other domains.  I'm
> assuming, however, that domains of the same type will be allowed to
> create connections between each other (which last I heard wasn't 
> implemented yet).

I assume that you speak about direct event channels
between user domains. The MAC is implemented. Today, all relevant communication
(device related) still goes through Dom0.

> I expect you're already planning this, but it seems to me that the
> privilege bit on domains should be replaced by system-level access
> controls, thus eliminating the distinction between driver and user
> domains.

Yes, we are planning. But we won't act until there
are actually driver domains other than dom0 with access to hardware. At
this point, the privileges seem to require changes anyway.

> Special hypervisor calls for accessing hardware
should be 
> granted in the policy on an as-needed basis.  The TCB for a domain
> is then the list of domains it depends upon, the hardware the 
> domains rely upon, and the hypervisor.  With sufficient hardware,
> different collections of domains will have different, although 
> overlapping, TCB's.

You are right, since driver domains have multiple
(but usually not all the types), the TCB regarding different types can
differ. Right now, only dom0 has multiple types (and all of them); therefore
we only have a single TCB even from this perspective. From a viewpoint
of the VMM MAC there will only be one TCB, which includes all multi-type
domains and the hypervisor (and a secure boot-process and policy mgmt not
to forget).

> You made some good points about what you're trying to accomplish with
STE:

> 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).
> 
> Followed by:

> 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).
> 
> I see two claims that are being made:
> 1. If domain A and domain B do not share a color, then a failure in
> one cannot disrupt the operation of the other domain
> 2. All other useful security policies can be built within the 
> constraints of the STE policy
>
> I currently don't believe claim 1 is true, because of the following
comment:

> 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. 

This multi-color domain is trusted (assuming TCB not
compromised) and is assumed to keep the virtual domains --which are single
typed-- strictly apart (isolated from each other).

> Thus domain C can provide a communication channel between A and B.
 
> A dependency between them can be created through this channel even
> though they have different colors.  This effectively undermines
the 
> value you claimed for having STE as it does not prevent unwanted 
> dependencies to limit the TCB.

The idea is that domain C is necessary and trusted.
Using STE, you focus the trust into this domain.

> To relate this to Rusbhy's work, I think the colors either need to
> be defined as wires or regimes.  Trying to say it's both is only
> causing problems as wires and regimes have opposing requirements.
> 
> If color's represent a regime, then I may believe your claim that
> the value for STE is in its ability to limit dependencies.  In
which
> case any domain that is assigned multiple colors is responsible for
> maintaining separation between the different colored domains it 
> communicates with, or it should fail to accept the policy if it 
> cannot do this.  The assertion is that any two domains without
a 
> shared color cannot communicate other than through allowed 
> communication with the outside world.  The exception is a possible
> trouble spot to be watched for and minimized, but is unavoidable.

This is the idea. I need to read a definition for
"regime".

> Once we have separation, then it is interesting to consider 
> independent policies for the colored regimes as a natural way to 
> create a layer on top of STE.  For example, each color may be
given 
> a security server and policy file.  The driver domains would
look up
> the shared color of the subject domain, then consult the color's 
> security server to make policy decisions.  A means for resolving
> color ambiguity is needed though.  Without separation, this wouldn't
> work as there may be channels enabled by STE through another domain
> that is not controlled by the second layer policy.

This is a very good idea and seems to coincide with
the layering of policies that we would like to experiment with. Let me
try to describe the separation/sharing objectives in layers:

The lowest layer is the hypervisor. It isolates domains
against each other by default and leaves only two doors open through which
domains can communicate (ignoring all side/covert channels): event channels
and shared memory.  Lowest layer means sharing of basic system hardware
resources.

The "next" level are the ACM/hooks that
guard these doors and allow domains to communicate through them only if
they share at least a color. Assuming we trust all multi-color domains,
then the ACM/hooks inside the hypervisor isolate sets of domains with the
same type. The multi-color driver domains are trusted to isolate the virtual
resources that they create and to enforce the STE policy (e.g., asking
a decision from the ACM) between those single-color virtual resources and
the single-color user domains trying to access them.

Up to this level (VMM), there is no information sharing
between colors. The only sharing is regarding physical hardware resources
but in a way that the separation of types is preserved withing the driver
domains.

In a third level (which is outside the VMM scope but
within our experimentation scope), there will be need to allow information
sharing between different types since this is how real-world applications
operate. This sharing is the most critical part because this sharing operates
on fine-grained objects (files) and subjects (processes). It will likely
require a MAC/MLS system configured to the application needs to get this
right.

Only on this third level is actual sharing of information
between domains.

> So far this seems reasonable for setting policies on domains that
> are outside the VMM.  What it lacks is the ability to set policy
for
> driver domains inside the VMM.
> 
> BTW, thanks for the references.

> 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). 
> 
> I had already printed and read the J.P. Anderson paper some time 
> ago.  Long read.  I've had no luck getting the Distributed
Secure 
> System paper, but I put in a request at the library.
>
> Dave
>
Regards
Reiner

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