WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

Re: [Xen-devel][Xense-devel][PATCH][XSM][1/4] Xen Security Modules Patch

To: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel][Xense-devel][PATCH][XSM][1/4] Xen Security Modules Patch
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Thu, 08 Mar 2007 19:06:38 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 08 Mar 2007 11:05:57 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1173377319.11144.74.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdhtOXBJIIfoM2oEduQtwAX8io7RQ==
Thread-topic: [Xen-devel][Xense-devel][PATCH][XSM][1/4] Xen Security Modules Patch
User-agent: Microsoft-Entourage/11.2.5.060620
On 8/3/07 18:08, "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx> wrote:

> The check on send, enables for the flask module the creation of a one-
> way event channel.  Flask can check whether A can send to B, but this
> does not imply that B can send to A.  The primary value for this check
> is in the construction of one-way information flows.

Fair enough.

> The pirq bindings are meant to protect the hypervisor against abuse by
> the control-plane, thereby ensuring that the control-plane cannot setup
> resource bindings that are prohibited by the policy.  The control-plane
> in this argument is decomposed or deprivileged by the running policy
> such that it is unable to cause a policy reload and circumvent these
> checks.

You can restrict this via the iocaps mechanism, and I'll bet you already
include a hook that could prevent the domain from modifying its own iocaps
in a disallowed way. :-)

> While the virq/ipi have local-domain scope, it is in the interest of
> comprehensiveness that this hooks exists.  For a domain running a
> general purpose OS, this hook has little value since anything checked
> here will always likely need to be granted.  However, light-weight
> domains for which the enforced policy could be justifiably more
> restrictive, would benefit from this hook.

I don't think this is true. Same applies to evtchn_close(): another entirely
local VM operation. It seems outside the scope of XSM policy to be hooking
those. If you were to go this route then wouldn't you essentially be arguing
for interception of *every* hypercall subcommand?

> Separate hooks does not necessarily mean separate permissions - the
> breakdown of permissions is module dependent.  Separate hooks allows for
> a narrower per-hook interface (ensuring that the hooks are unlikely to
> be abused for non-security purposes) and makes it unlikely that a given
> hook will be separated from or lose context with the critical code path.

If new critical code paths are added then XSM could end up with a set of
critical paths that it doesn't hook at all. That would be less of a problem
if the hooks aren't pushed way down into hypercall subcommands. I guess you
can argue this one either way. With this scheme you don't end up having to
demux the hypercall subcommands in every XSM module implementation.

 -- Keir


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

<Prev in Thread] Current Thread [Next in Thread>