All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Christian Limpach <Christian.Limpach@xensource.com>
Cc: xen-staging@lists.xensource.com, xen-devel@lists.xensource.com
Subject: Re: RE: [Xen-staging] [xen-unstable] hvm: Remove access to QEMU monitor inVNC server
Date: Tue, 27 Mar 2007 23:47:24 +0100	[thread overview]
Message-ID: <20070327224724.GF3126@redhat.com> (raw)
In-Reply-To: <0326530267625D42A4E36594FDD0D1432EBB1F@exchpamain.ad.xensource.com>

On Tue, Mar 27, 2007 at 03:40:35PM -0700, Christian Limpach wrote:
> > From: Daniel P. Berrange [mailto:berrange@redhat.com] 
> >
> > 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  -=| 

  reply	other threads:[~2007-03-27 22:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200703271524.l2RFOMNg003926@latara.uk.xensource.com>
2007-03-27 21:06 ` [Xen-staging] [xen-unstable] hvm: Remove access to QEMU monitor inVNC server Christian Limpach
2007-03-27 21:18   ` Daniel P. Berrange
2007-03-27 21:32     ` Christian Limpach
2007-03-27 22:28       ` Daniel P. Berrange
2007-03-27 22:40         ` Christian Limpach
2007-03-27 22:47           ` Daniel P. Berrange [this message]
2007-03-27 21:24   ` Anthony Liguori
2007-03-27 21:41     ` Christian Limpach
2007-03-27 21:56       ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070327224724.GF3126@redhat.com \
    --to=berrange@redhat.com \
    --cc=Christian.Limpach@xensource.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-staging@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.