Re: [Xense-devel] Labeling resources

[David Palmer <dwpalmer.xense@xxxxxxxxx>]

I've been out for a couple weeks helping my wife with our newborn
son.  It's been great learning about sleep deprivation and what it
means to be a father.  Please bear with me as I try to get my
brain unclouded and put together intelligible sentences and coherent
paragraphs.

I think we'd agree that the basic premise to mandatory access control
(MAC) is that if subject X wants to access object Y, then a trusted
third party, subject Z, must be consulted to grant or deny the
access.  Otherwise, if Y is a subject that makes the decision for
itself, then we have discretionary access control (DAC).  This
latter method is known to be ineffective and is why MAC is used
instead.  If we do not agree on this, please let me know.

So, what I see is that the dom_Network may try to access
dom_Storage.  For this to happen, a third party, say the
hypervisor, must decide whether this access is allowed.  Once this
basic connection is allowed, then we introduce partition objects. 
For dom_Network to access a partition, dom_Storage is consulted to
decide whether the access is allowed.  In this manor, we
consistently provide MAC without regressing to DAC.  How
dom_Storage wants to manage its resources and provide MAC is up to
dom_Storage.  That's fine, though it may be nice if it could use
and extend the existing hypervisor based MAC if it is found to be
adequate.

The hypervisor, however, provides a basic STE policy for managing
connections between domains.  As a security architect, I need the
ability to read the policy and make strong assertions about the
security of the platform.  If I have to read and evaluate too much
source code, I will fail at my job.  I rather like the separation
kernel work done by John Rushby in 1981, "Design and Verification of
Secure Systems".  You've probably read his papers, but I'll attach
a couple here for those who haven't.  The basic idea is that the
separation kernel only provides one security property - separation of
system components.  This enables looking at the system as a
collection of independent devices with dedicated wires between
them.  Communication is only possible where wires exist. 
With this model, I can consider a specific threat and reason about what
must fail in order for attacks to be possible.   This lets me
focus efforts on the critical components for the known threat and not
worry about other components.  The security policy file for MAC
enables dynamically reconfiguring the wiring for different functional
goals while preserving assurances for security goals.  It's
important then that I can look at the policy file and reason about what
must happen for certain threats to be realized.  I'm finding this
difficult to do with STE as defined in ACM.  Much of this is
because I only want to trust the network domain with network objects, I
only want to trust the storage domain with storage objects, and I only
trust the hypervisor with inter-domain interactions (esp. the wiring
between system components).

Using the defined STE, how do you create an effective policy for making
security assurances about the system?  Maybe showing an example
threat (adversarial goal) that is addressed based on an STE policy
would help.  Using the example policy provided with the XenSE
sources would be a good starting place - what security assurances can
you claim from this policy?  If you have to punt this to resource
managers (network, storage, etc), then what value does the hypervisor's
STE policy have?  I agree that the policy semantics should be
simple, but is it overly simplified to where it's no longer useful?

BTW, if you have any favorite security related papers, please post
references to them.  I'm always looking for good reading material.

Dave

On 9/19/05, Reiner Sailer <sailer@xxxxxxxxxx> wrote:

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

rushby81design.pdf
Description: Adobe PDF document

rushby84trusted.pdf
Description: Adobe PDF document

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