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

RE: [Xen-devel] RE: [Xen-staging] [xen-unstable] hvm: Remove access to Q

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [Xen-staging] [xen-unstable] hvm: Remove access to QEMU monitor inVNC server
From: "Christian Limpach" <Christian.Limpach@xxxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 15:40:35 -0700
Cc: xen-staging@xxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 27 Mar 2007 15:40:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070327222851.GE3126@xxxxxxxxxx>
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>
References: <200703271524.l2RFOMNg003926@xxxxxxxxxxxxxxxxxxxxxxx> <0326530267625D42A4E36594FDD0D1432EBA8A@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20070327211826.GD3126@xxxxxxxxxx> <0326530267625D42A4E36594FDD0D1432EBAA7@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20070327222851.GE3126@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acdwv1Aiz9XSLYQ8T2K4Wv0jYBpNPQAADuCA
Thread-topic: [Xen-devel] RE: [Xen-staging] [xen-unstable] hvm: Remove access to QEMU monitor inVNC server
> From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx] 
>
> The $DISPLAY that a guest connects to has to be specified by 
> the person
> creating the guest in the first place. So the Dom0 admin 
> would be making
> a concious decision to give that local user access to the 
> guest display
> via their desktop - in this scenario the local user & admin are almost
> certainly one & the same person, so its not really a huge 
> issue. Although
> I guess there could be times when you wished to delegate the 
> SDL display
> access without the monitor. So really Anthony's suggestion is 
> a good long
> term approach to deal with the issue of monitor access.

I still think that giving the local user access to the guest display is
a bit different than giving the local user access to the monitor which
lets the local user gain root privileges on the host.

One could apply your logic to the VNC scenario just as well -- the admin
must have made the conscious decision to give the remote user access to
the guest display, so why shouldn't the remote user get the same chance
of compromising the local host ;-)

> > ?? You get access to the guests serial port through a 
> virtual console in
> > VNC/SDL, how is that a privilege escalation?
> 
> I didn't mean privilege escalation - I meant they have 
> unauthorized access 
> to privileged hardware - local users do not typically have 
> permissions to 
> access the devices /dev/ttyS* unless they're root. The 
> monitor allows them 
> this access without being root.

Stop!  You seem to be confusing some things here.  I think we all agree
that giving access to the monitor is a security issue.  But there's
nothing wrong with the default qemu serial config which exposes the
_guest's_ first serial port on a virtual console.  This never gets
anywhere close to the host serial devices.

> > Don't you think that having the monitor (and the serial port) not
> > exposed by default through VNC/SDL is a sufficient and more 
> flexibel fix
> > for the security issue? 
> 
> Yes I do - as I said, XenD should take complete control of 
> the monitor 
> itself rather than allowing user access via the console. My patch was
> merely the quickest fix to address the issue. Anthony's suggestion is
> a good one to follow as a permanent solution, because it allows the 
> privileged Dom0 admin to still pass commands through to the monitor.
> Still needs someone to take the time to write such an 
> approach though...

Glad you agree, although it's a bit in a weird way by going off on a
tangent ;-)

    christian

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