Re: [Xen-devel] RE: [Xen-staging] [xen-unstable] hvm: Remove access to QEMU monitor inVNC server

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Tue, Mar 27, 2007 at 03:40:35PM -0700, Christian Limpach wrote:
> > 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.

Ahhhh, I see what you mean - you're referring to the ability to map the
backend of the guest virtual serial port into a VC of the guest!

I was talking about the ability to remap the backend of a guest serial
port at runtime, eg ability to do 'change serial /dev/ttyS0' in the monitor

So we're talking about completely different things :-)

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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