WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

[Xen-devel] Re: [Xense-devel] [PATCH] ACM: adding get_ssid command and c

To: dwpalmer.xense@xxxxxxxxx
Subject: [Xen-devel] Re: [Xense-devel] [PATCH] ACM: adding get_ssid command and cleanup
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Sat, 3 Sep 2005 16:16:08 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Stefan Berger <stefanb@xxxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 03 Sep 2005 20:14:07 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <7d415b28050903094917479914@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx


David Palmer <dwpalmer.xense@xxxxxxxxx> wrote on 09/03/2005 12:49:01 PM:

> Yes, that helps considerably.  I had the mistaken impression that
> you were implementing the Flask architecture.  From the papers I've
> read, it calls for object managers and a security server.  Each
> object manager is only concerned with object specific knowledge for
> policy enforcement.  Object managers rely on a central security
> server to make policy decisions.  The security server has the sole
> responsibility of interpreting the policy.  This is clearly not the
> architecture you envision for sHype.

You are right. On one hand, are applying a flask-like architecture inside the hypervisor where we have "hooks" around operations on eventchannels and grant-tables. These hooks actually do not know about policies but call into the ACM (security server).

On the other hand, since some objects are located outside the hypervisor (virtual resources based on peripherals), we need to modularly extend this basic access control to allow certain trusted domains (device domains). Such domains are part of the access control infrastructure; they are not user domains.

> Instead, what I hear you saying sounds like a collection of resource
> reference monitors that follow a global policy that applies to all
> reference monitors.


yes.

> 1. Each reference monitor makes policy decisions and enforces them
> for its resources.
>
> 2. A central policy server is used to provide the relevant portions
> of the global policy to the reference monitors.
>
> 3. Each reference monitor faithfully interprets the global policy
> according to the common policy semantics.
>
> 4. Each reference monitor enforces the global policy in that it does
> not allow any more access than what is permitted by the policy
> semantics.  It may choose to grant less access as long as it does
> not change the meaning of the global policy.

yes.

> For example, lets consider the case where I have a domain that
> provides both a "privileged" and "unprivileged" interface to its
> resources.  The global policy allows a red and a black domain to
> each connect to the resource domain.  The resource domain may choose
> to provide different levels of access to red and black.  It should
> not interpret the global policy differently, but instead it can
> honor a local policy that names the red and black domains.
>
> Have you published a paper detailing this architecture and how it
> compares with other architectures?  It would be interesting to go
> over it in detail and see what you have learned about the approach.

Will be on ACSAC 2005 (December, Tuscon) We are working on it ;_)

> In your messages, you note that it is important that the global
> policy has a consistent meaning for all reference monitors, and that
> the architecture supports the ability to change the meaning of the
> policy in the future.
>
> 1. Doesn't optimizing the policy decision logic for each resource
> monitor increase the risk that there will be differences in how each
> of them interprets the global policy?

The current policies are simple so it should be possible to get this right (eventually). The more difficult part is to ensure that the device domains are small and tight enough to keep access to resources of different types safely apart (MAC confinement). Minimal Linx + enforcment (e.g. SELinux), micro-kernels, ... might be interesting experiment candidates and we encourage experiments.

> Although we all try to write perfect code, we certainly have to
> accept that it doesn't generally happen.  There is an advantage to
> having a single golden implementation where defects can be fixed
> such that all resource managers benefit.  Independent optimizations
> for the policy decision logic in each resource monitor increases the
> chances for defects that have to be fix independently.  
> Unfortunately, testing tends not to work well for eliminating
> security vulnerabilities as it only finds the few that were tested for.

This is one correct side of arguments. The other is that modularity has advantages too. We try to minimize the code intrusiveness by controlling access at the natural points where we have direct control on access and all necessary information to derive the access decision. Both alternative ways should be explored.

> 2. How can semantic changes in the global policy be made?
>
> If each resource monitor is responsible for interpreting the policy
> consistently with each other, aren't they locked into the specific
> semantics of the policy they understand?  In the worse case, won't
> this lead to needing to rewrite each reference monitor in order to
> add or alter the policy semantics?
>
> I'm concerned that if I start implementing my own reference monitor
> with the given get_ssid() function, I'll end up having to rewrite it
> completely as it won't be consistent with the solution you have in
> mind for addressing the goals of providing consistent policy
> semantics and allowing them to be changed in the future.
>
> Dave

All reference monitors (hypervisor + device domains of multiple types) are part of the policy enforcement; from an access control viewpoint, they are more part of the hypervisor than they are a real domain. If you change the policy, then you need to do this in all the elements. No different from any other reference monitor implementation. Of course, the enforcement for device domains should ideally be a pretty small patch to the driver code leveraging existing OS controls (e.g., SELinux) to take over the confinement/isolation part inside the domain.

The hypervisor-level access control is supposed to be simple but strong (small TCB). It is not one of our current goals to optimize for changes in the semantics of a policy since this is best done by defining a new policy and implementing respective code. The coarse granularity of control rather suggests that the policy should be a smallest common denominator and a strong safety-net.

There is certainly room for choices while we are moving into device domains and it can be pretty interesting to experiment with different approaches for this integration.

I believe that your original suggestion is a good one and that we should think about introducing an additional ACM call that allows to retrieve a policy decision for the current policy based on two ssidrefs or one ssidref and a domain id (whatever is available in the device domain) to ensure that such experiments can apply to the full range of possible enforcement options in device domains and to arrive at the best architecture and not some local maxima.

We have so far used the following criteria when evaluating hypervisor security architecture alternatives:

a) performance (without this it cannot survive in commercial environments; see history)

b) minimize code-intrusiveness (without this, the security architecture code will be subject to endless changes when other hypervisor code is optimized and maintained or we end up re-writing the hypervisor; see history)

c) simplicity (minimal TCB but considering a) and b))
                                       
Regards
Reiner
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>