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/
Home Products Support Community News


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

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 :-)

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