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

Reiner Sailer
Sat, 03 Sep 2005 20:16:08 -0000

David Palmer <dwpalmer.xense@gmail.com> 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