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

[Pat Huntington <pat_huntington@xxxxxxxxx>]

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@xxxxxxxxxx> wrote:

> > ------------------------------
> > 
> > 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>
_______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 


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

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