Re: [Xen-devel] ACM ternary ops?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] ACM ternary ops?

Michael LeMay
Reiner,

Thank you for that detailed explanation, it's great to hear that you'll
be integrating additional networking hooks into ACM.  Are they currently
available in any public repositories?  After this discussion, I've
decided that the appropriate approach to my problem would be to add more
networking hooks as well, although I haven't yet determined exactly
where I will need them.  I would hate to recreate your work or conflict
with it.

Since you asked what exactly I'm looking for, I'll try to explain it
briefly here.  I'd like to have a general network access control
architecture at the hypervisor level, that can control network
communications to and from any domU.  It shouldn't matter whether the
communications are intended for other VMs on the same machine, or some
external host.  Originally, I had wanted to have some control over which
IP addresses the domU's are permitted to communicate with.  However,
after this discussion, I can see that a better approach would be to
restrict the communications from all VMs such that they are unable to
make any connections, but simply route connections through a designated
VM that enforces an appropriate network policy from userspace or using
iptables, etc.

 -- Michael

Reiner Sailer wrote:

>
> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 30 May 2006 08:52:48 -0400
> > From: Michael LeMay <[hidden email]>
> > Subject: [Xen-devel] ACM ternary ops?
> > To: [hidden email]
> > Message-ID: <[hidden email]>
> > 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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] ACM ternary ops?

Reiner Sailer

Michael,

I agree with your conclusion that your proposed network control might be most efficient if it resides inside a VM and leverages the existing mandatory ACM controls in Xen to ensure that your network policy VM is always in the path of communication. The ACM policy setup for such a configuration is simple.

> Michael LeMay <[hidden email]> wrote:
> However,
> after this discussion, I can see that a better approach would be to
> restrict the communications from all VMs such that they are unable to
> make any connections, but simply route connections through a designated
> VM that enforces an appropriate network policy from userspace or using
> iptables, etc.


From your e-mail I understand that you are thinking of implementing controls in a specialized Xen domain (probably Dom0 for the start), which further refines the traffic that the hypervisor ACM policy allows to pass, e.g. based on finer-grained access control information and access rules (addresses, services, ...). This makes sense and such controls can also be moved into a network device domain if network traffic handling is moving into its own small domain in the future. There is already some traffic control implemented in Xen in Dom0 (anti-spoof etc.), which you have probably already looked at.

For your planning, I can give you "very rough" estimates for the public availability of our upcoming ACM extensions:
The patches that enable the hypervisor ACM to control access of domains to disk/image file storage resources (xm, xend, blockback drivers) will start to appear within a few days on this mailing list. The patches that enable the hypervisor ACM to apply coarse grained control--based on domain labels--to network traffic through Dom0 (netback driver) between local domains will start to appear on this list around the end of June.

I am looking forward to hear more from your project on this list as you go along.

Regards
Reiner




Michael LeMay <[hidden email]>

06/05/2006 11:25 AM

To
Reiner Sailer/Watson/IBM@IBMUS
cc
[hidden email]
Subject
Re: [Xen-devel] ACM ternary ops?





Reiner,

Thank you for that detailed explanation, it's great to hear that you'll
be integrating additional networking hooks into ACM.  Are they currently
available in any public repositories?  After this discussion, I've
decided that the appropriate approach to my problem would be to add more
networking hooks as well, although I haven't yet determined exactly
where I will need them.  I would hate to recreate your work or conflict
with it.

Since you asked what exactly I'm looking for, I'll try to explain it
briefly here.  I'd like to have a general network access control
architecture at the hypervisor level, that can control network
communications to and from any domU.  It shouldn't matter whether the
communications are intended for other VMs on the same machine, or some
external host.  Originally, I had wanted to have some control over which
IP addresses the domU's are permitted to communicate with.  However,
after this discussion, I can see that a better approach would be to
restrict the communications from all VMs such that they are unable to
make any connections, but simply route connections through a designated
VM that enforces an appropriate network policy from userspace or using
iptables, etc.

-- Michael

Reiner Sailer wrote:
>
> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 30 May 2006 08:52:48 -0400
> > From: Michael LeMay <[hidden email]>
> > Subject: [Xen-devel] ACM ternary ops?
> > To: [hidden email]
> > Message-ID: <[hidden email]>
> > 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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] ACM ternary ops?

Pat Huntington
In reply to this post by Michael LeMay

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 <[hidden email]> wrote:

> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 30 May 2006 08:52:48 -0400
> > From: Michael LeMay <[hidden email]>
> > Subject: [Xen-devel] ACM ternary ops?
> > To: [hidden email]
> > Message-ID: <[hidden email]>
> > 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
> [hidden email]
> 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
[hidden email]
http://lists.xensource.com/xense-devel