[Xense-devel] Fw: [Xen-devel] ACM ternary ops?

[Reiner Sailer <sailer@xxxxxxxxxx>]

> ------------------------------
> 
> Message: 4
> Date: Tue, 30 May 2006 08:52:48 -0400
> From: Michael LeMay <lemaymd@xxxxxxxxxxx>
> Subject: [Xen-devel] ACM ternary ops?
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Message-ID: <447C4020.4020008@xxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hello all,
> 
> I am interested in adding support for user-defined mandatory network
> access control policies to the existing ACM policy framework.  The
most 
> logical way to do this would be to add more hooks to handle networking
> and then define another policy module, like chinese wall and type
> enforcement.  However, it doesn't feel right to add a "ternary_ops"
> structure that is invoked after "secondary_ops".  Is
there any 
> reasonable justification for not including a link in each ops structure
> that points to the next policy module in the chain?  Essentially,
I'd 
> like to convert the current n-pointer structure to the following 
> linked-list structure:
> 
> acm_primary_ops -> acm_secondary_ops -> acm_ternary_ops ->
... -> NULL
> 
Hi Michael,

to be able to answer more (than I do below) to your
point, I need to know what "user-defined" policy do you aim to
enforce? Is it a finer-grained operating system policy (based on OS structures,
such as IP address or similar things etc.)?

If it is an operating system policy, then the policy
should be implemented, decided, enforced, and managed in the operating
system (e.g., IP tables, SELinux,...) and probably not in the hypervisor.
The major focus of the ACM hypervisor security module is to keep the hypervisor
code as small as possible and robust, and the hypervisor security guarantees
easy to understand. --> only integrate what needs to be there. Higher
layer security can and should be handled in the higher layers (OS, Middleware,
Apps.).

Regarding hypervisor ACM network enforcement: We are
currently integrating network packet policy enforcement into the Dom0 netback
interface to control local network traffic (enforcing the simple type-enforcement
policy based on acm labels of sending/receiving domain). In this case,
we don't need new policies but integrate the existing acm_getdecision hypervisor
call into the netback code to decide if a packet is passed or discarded
between virtual network interfaces. This solutions appears to be a good
fit for local traffic because the virtual network resource is part of the
hypervisor environment and because the network policy is based on hypervisor
structures: domains (not IP...). Other enforcement is be needed to guard
external packets and such controls (at least our prototypes) use OS-level
security, such as SELinux.

>Is there any 
> reasonable justification for not including a link in each ops structure
> that points to the next policy module in the chain? 

Every policy layer operating on the same hooks might
keep internal state information, which must be rolled back if an access
is denied by a policy component called "later" for the same hook.
The chinese wall and the simple type enforcement policy components were
chosen to build a hypervisor policy because they complete each other (one
controls which domains can start on a system, the other controls how started
domains can share information/communicate) and because they offer a good
abstraction (workload = Doms + resources) based on which security guarantees
are understood.

Running more than two policy components at the same
time would require to show that you really need all these policies active
at the same time. Otherwise, it seems more appropriate to define a new
hypervisor policy that can be configured instead of the existing ones (assuming
this new policy belongs into the hypervisor layer).

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