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
 
   
 

xen-devel

[Xen-devel] Re: Unofficial Xen 2.0 debian packages kinda broken

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: Unofficial Xen 2.0 debian packages kinda broken
From: Nuutti Kotivuori <naked@xxxxxx>
Date: Sat, 30 Oct 2004 13:57:30 +0300
Cache-post-path: aka.i.naked.iki.fi!unknown@xxxxxxxxxxxxxxxxxx
Cancel-lock: sha1:fgnziTT1TkwmPVsgI4I5VYuxR0A=
Delivery-date: Sat, 30 Oct 2004 11:59:10 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Organization: Ye 'Ol Disorganized NNTPCache groupie
References: <87is94fh2q.fsf@xxxxxxxxxxxxxxxxxx> <1098418544.32097.136.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <877jpjdj6q.fsf@xxxxxxxxxxxxxxxxxx> <1098538551.32097.201.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <871xfpczo9.fsf@xxxxxxxxxxxxxxxxxx> <1098540624.32097.229.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <87u0slbj69.fsf@xxxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0410291334070.1271@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux)
Adam Heath wrote:
> Do you really want to allow your virtualized users to be able to
> change the kernel?

Yes. In some cases.

There are cases where strict separation is not an issue, where
granting priviledges does not really matter.

And even where strict separation is an issue, with Xen there shouldn't
be any problem, should there?

I mean, with UML obviously if the kernel is compromised, it can access
everything the binary can on the host - and needs to be restricted
there somehow. And if compromising the kernel shouldn't be possible,
it gives quite a bit of restrictions on the guest side - like no
modules allowed and so.

But with Xen, the separation is on a lower layer, and there should be
no problem allowing custom built kernels with custom patches or binary
modules or whatnot.

But in any case, it is simply a choice there.

-- Naked




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel