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