Re: [Xense-devel] Labeling resources

[David Palmer <dwpalmer.xense@xxxxxxxxx>]

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:

* 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. 
* 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?
* 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)?
* 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.

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

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.

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.

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.

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



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