Re: [Xense-devel] Labeling resources

[Reiner Sailer <sailer@xxxxxxxxxx>]

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