[Xen-devel] Re: [Xense-devel] [PATCH] ACM: adding get_ssid command and cleanup

[Reiner Sailer <sailer@xxxxxxxxxx>]

David Palmer <dwpalmer.xense@xxxxxxxxx> wrote
on 09/03/2005 12:49:01 PM:

> Yes, that helps considerably.  I had the mistaken impression
that 
> you were implementing the Flask architecture.  From the papers
I've 
> read, it calls for object managers and a security server.  Each
> object manager is only concerned with object specific knowledge for
> policy enforcement.  Object managers rely on a central security
> server to make policy decisions.  The security server has the
sole 
> responsibility of interpreting the policy.  This is clearly not
the 
> architecture you envision for sHype.

You are right. On one hand, are applying a flask-like
architecture inside the hypervisor where we have "hooks" around
operations on eventchannels and grant-tables. These hooks actually do not
know about policies but call into the ACM (security server).

On the other hand, since some objects are located
outside the hypervisor (virtual resources based on peripherals), we need
to modularly extend this basic access control to allow certain trusted
domains (device domains). Such domains are part of the access control infrastructure;
they are not user domains.

> Instead, what I hear you saying sounds like a collection of resource
> reference monitors that follow a global policy that applies to all
> reference monitors.

yes.

> 1. Each reference monitor makes policy decisions and enforces them
> for its resources.
> 
> 2. A central policy server is used to provide the relevant portions
> of the global policy to the reference monitors.
> 
> 3. Each reference monitor faithfully interprets the global policy
> according to the common policy semantics.
> 
> 4. Each reference monitor enforces the global policy in that it does
> not allow any more access than what is permitted by the policy 
> semantics.  It may choose to grant less access as long as it
does 
> not change the meaning of the global policy.

yes.

> For example, lets consider the case where I have a domain that 
> provides both a "privileged" and "unprivileged"
interface to its 
> resources.  The global policy allows a red and a black domain
to 
> each connect to the resource domain.  The resource domain may
choose
> to provide different levels of access to red and black.  It should
> not interpret the global policy differently, but instead it can 
> honor a local policy that names the red and black domains.
> 
> Have you published a paper detailing this architecture and how it
> compares with other architectures?  It would be interesting to
go 
> over it in detail and see what you have learned about the approach.

Will be on ACSAC 2005 (December, Tuscon) We are working
on it ;_)

> In your messages, you note that it is important that the global 
> policy has a consistent meaning for all reference monitors, and that
> the architecture supports the ability to change the meaning of the
> policy in the future.
> 
> 1. Doesn't optimizing the policy decision logic for each resource
> monitor increase the risk that there will be differences in how each
> of them interprets the global policy?

The current policies are simple so it should be possible
to get this right (eventually). The more difficult part is to ensure that
the device domains are small and tight enough to keep access to resources
of different types safely apart (MAC confinement). Minimal Linx + enforcment
(e.g. SELinux), micro-kernels, ... might be interesting experiment candidates
and we encourage experiments.

> Although we all try to write perfect code, we certainly have to 
> accept that it doesn't generally happen.  There is an advantage
to 
> having a single golden implementation where defects can be fixed 
> such that all resource managers benefit.  Independent optimizations
> for the policy decision logic in each resource monitor increases the
> chances for defects that have to be fix independently.  
> Unfortunately, testing tends not to work well for eliminating 
> security vulnerabilities as it only finds the few that were tested
for.

This is one correct side of arguments. The other is
that modularity has advantages too. We try to minimize the code intrusiveness
by controlling access at the natural points where we have direct control
on access and all necessary information to derive the access decision.
Both alternative ways should be explored.

> 2. How can semantic changes in the global policy be made?
> 
> If each resource monitor is responsible for interpreting the policy
> consistently with each other, aren't they locked into the specific
> semantics of the policy they understand?  In the worse case,
won't 
> this lead to needing to rewrite each reference monitor in order to
> add or alter the policy semantics?
> 
> I'm concerned that if I start implementing my own reference monitor
> with the given get_ssid() function, I'll end up having to rewrite
it
> completely as it won't be consistent with the solution you have in
> mind for addressing the goals of providing consistent policy 
> semantics and allowing them to be changed in the future.
> 
> Dave

All reference monitors (hypervisor + device domains
of multiple types) are part of the policy enforcement; from an access control
viewpoint, they are more part of the hypervisor than they are a real domain.
If you change the policy, then you need to do this in all the elements.
No different from any other reference monitor implementation. Of course,
the enforcement for device domains should ideally be a pretty small patch
to the driver code leveraging existing OS controls (e.g., SELinux) to take
over the confinement/isolation part inside the domain.

The hypervisor-level access control is supposed to
be simple but strong (small TCB). It is not one of our current goals to
optimize for changes in the semantics of a policy since this is best done
by defining a new policy and implementing respective code. The coarse granularity
of control rather suggests that the policy should be a smallest common
denominator and a strong safety-net.

There is certainly room for choices while we are moving
into device domains and it can be pretty interesting to experiment with
different approaches for this integration.

I believe that your original suggestion is a good
one and that we should think about introducing an additional ACM call that
allows to retrieve a policy decision for the current policy based on two
ssidrefs or one ssidref and a domain id (whatever is available in the device
domain) to ensure that such experiments can apply to the full range of
possible enforcement options in device domains and to arrive at the best
architecture and not some local maxima.

We have so far used the following criteria when evaluating
hypervisor security architecture alternatives:

a) performance (without this it cannot survive in
commercial environments; see history)

b) minimize code-intrusiveness (without this, the
security architecture code will be subject to endless changes when other
hypervisor code is optimized and maintained or we end up re-writing the
hypervisor; see history)

c) simplicity (minimal TCB but considering a) and
b))
               
                     
 
Regards
Reiner
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel