| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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 :-)
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
|
|
|
| |
|
Home