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: xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xense-devel] Labeling resources
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 20 Sep 2005 03:41:13 +0100
Delivery-date: Tue, 20 Sep 2005 02:37:07 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <OF66E77649.D1264780-ON8525707D.0011AB06-85257082.0009597D@xxxxxxxxxx>
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>
References: <OF66E77649.D1264780-ON8525707D.0011AB06-85257082.0009597D@xxxxxxxxxx>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8
> 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,

I'd like to jump in here and point out that writing a XenSE-related section(s) 
for the user manual would be a good way for someone to learn.

Just sayin... ;-)

Cheers,
Mark

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