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
|
Home