ACM ternary ops?

ACM ternary ops?

[Michael LeMay]

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


Thanks.

Re: ACM ternary ops?

[Reiner Sailer]

[-- Attachment #1.1: Type: text/plain, Size: 3789 bytes --]

> ------------------------------
> 
> Message: 4
> Date: Tue, 30 May 2006 08:52:48 -0400
> From: Michael LeMay <lemaymd@lemaymd.com>
> Subject: [Xen-devel] ACM ternary ops?
> To: xen-devel@lists.xensource.com
> Message-ID: <447C4020.4020008@lemaymd.com>
> 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

[-- Attachment #1.2: Type: text/html, Size: 4361 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: ACM ternary ops?

[Pat Huntington]

What if you assign a pci NIC to the VM directly, then
the VM has full control over the device without any
dom0 backend, wouldn't that bypass the ACM checks in
netback?

--- Reiner Sailer <sailer@us.ibm.com> wrote:

> > ------------------------------
> > 
> > Message: 4
> > Date: Tue, 30 May 2006 08:52:48 -0400
> > From: Michael LeMay <lemaymd@lemaymd.com>
> > Subject: [Xen-devel] ACM ternary ops?
> > To: xen-devel@lists.xensource.com
> > Message-ID: <447C4020.4020008@lemaymd.com>
> > 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>
_______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com