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

Re: [Xense-devel] Labeling resources

To: David Palmer <dwpalmer.xense@xxxxxxxxx>
Subject: Re: [Xense-devel] Labeling resources
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Mon, 19 Sep 2005 21:42:04 -0400
Cc: xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 Sep 2005 01:39:41 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <7d415b28050901200910287748@xxxxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
Sensitivity:

Hi David,

after discussing the background for the access control framework for Xen in our earlier mails, I'd like to address here the remaining questions of your earlier mail.

xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 09/01/2005 11:09:19 PM:

> Reiner,
>
> Thanks for taking the time to reply to my questions.  I'm very
> curious about where you're going with ACM and want to contribute
> code if I can get the powers that be to cooperate.

We welcome contributions to the access control framwork in Xen, ranging from observations to code enhancements, additions (e.g., label definitions for specific application environments) , documentation in the Xen style, code analysis and debugging. Services that extend the existing Xen security policy guarantees into (trusted, small) domains are especially welcome, e.g., for securely sharing disk or display.

> I spent a little time reviewing the chwall_ste policy to understand
> where you are headed.  
>
> I was initially thrown off by the use of ste_PersonalFinances with
> multiple domains.  This included dom_HomeBanking, dom_Network, and
> dom_LogicalDiskPartition1.  This allows dom_Network to directly
> access dom_LogicalDiskPartition1 and vise versa.  Expect that this
> was not intended.


To give some assumptions of this policy:
a) We assume that dom_NetworkDomain and dom_StorageDomain enforce this confinement of the different types inside their domain. This is implemented using OS controls (we are currently experimenting with several controls ranging from proprietary  hooks to LSM-SELinux hooks to implement this guarantee).

b) The current STE policy is intended as a very small example, where we don't assume that dom_HomeBanking is a domain that separates networking from partition data (in a mandatory access enforcement sense).

>To be specific about the allowed interactions, I
> replaced the ste_PersonalFinances type with
> ste_PersonalFincancesNetwork and ste_PersonalFinancesPartition.  I
> did the same with ste_InternetInsecure.  This ensures that
> dom_Network and dom_StorageDomain never directly talk to each other.

You can certainly do this. However, the information can still flow between dom_Network and dom_Storagedomain through dom_HomeBanking. You create a multi-typed domain dom_HomeBanking (ste_PersonalFinancesNetwork and ste_PersonalFinancesPartition. This makes sense if you assume dom_HomeBanking enforces the confinement of those types (we don't in our example).

> I did this to help see what would happen with resources as this
> relates to the limitations I'm encountering trying to use sHype .  
> There is still some abiguity with a few of the labels, but I'm more
> concerned about the following questions.
>
> How does the hypervisor know that these labels actually identify a
> specific hardware device?  I expect that the hypervisor wouldn't
> want to know anything more than the IRQ and address ranges for each
> device.  How do you intend to handle the association so that the ACM
> can make access decisions when resources are allocated to domains?

We have talked about some of these questions in the earlier mails. Here the enforcement specifics for the example above:

a) The hypervisor (in the above example) enforces the common type ste_PersonalFinances among the domains dom_NetworkDomain, dom_StorageDomain, and dom_HomeBanking. This can be enforced autonomously by the hypervisor based on controls around event channels and shared memory (given the default isolation of the other resources inside the hypervisor).

b) When assigning the hard drive to the StorageDomain, the domain management must enforce the types of res_harddrive and dom_StorageDomain (controls to be implemented once assigning of hardware to domains other than dom0 is available in Xen).

c) Finally, the hypervisor relies on dom_StorageDomain to control access to its logical partitions created out of the hard drive by using the resource label res_LogicalDiskPartition1 and the domain label dom_HomeBanking (they share the type ste_PersonalFinance). Controls must be implemented into any multi-color domain, especially into the storage and networking domains, which constitute parts of the hypervisor access control framwork. [note: other hypervisors might be able to control disk access inside the hypervisor; in this case, the hypervisor can decide and enforce the access without relying on a specialized domain]. If the complete hard drive would be assigned to dom_HomeBanking (not just one partition), then there is no need for a storage domain at all; on a client example, this exclusive usage cannot be assumed but on server systems, this might be a viable simplification. c) does would not apply in this case, a) and b) would still be necessary.

Above points b) and c) motivate very small and tight domains for virtualizing network and storage since these domains will be part of the Trusted Computing Base for the mandatory access control framwork. Other components of this TCB are the hypervisor/bootloader, the policy, and to some degree the domain-management.

> The other issue has to do with the res_LogicalDiskPartition1 and 2.
> Clearly this is not a resource the hypervisor knows anything about
> and is the responsiblity of dom_StorageDomain.  


correct.

>I expect that
> dom_StorageDomain will make calls into the hypervisor for the ACM to
> make access decisions.  


See other mails. Two possibilities:
a) query hypervisor ACM for policy decision (which "domain" hooks would need to be defined for domain queries?)
b) query hypervisor ACM for label information (based on domain id or ssidref) and decide about access locally within the storage domain)

>There needs to be some way for dom_Storage
> domain to identify a resource label with the physical resource.  
> Doesn't this need to be explicit in the label template?  What plans
> do you have for handling this?  


The way resources are represented and setup in Xen has just changed. One way would be to attach the security label (i.e. ssidref) to resource configurations the same way they are added to domain configurations. This represents current work. The policy hints to this possiblity by using hda1 etc. inside the label name.

>For example, the entry for the
> dom_Storage label could list the resources that are available from
> that domain with a <Resource> tag.  Within the <Resource> entry.
> there could be an <id> tag providing a numerical identifier that the
> dom_StorageDomain interprets to be a partition number.  

This makes sense, too.

> Thanks,
> Dave

Thanks for your valuable questions.

Reiner
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
<Prev in Thread] Current Thread [Next in Thread>