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:28:52 +0100	[thread overview]
Message-ID: <20070327222851.GE3126@redhat.com> (raw)
In-Reply-To: <0326530267625D42A4E36594FDD0D1432EBAA7@exchpamain.ad.xensource.com>

On Tue, Mar 27, 2007 at 02:32:00PM -0700, Christian Limpach wrote:
> > From: Daniel P. Berrange [mailto:berrange@redhat.com] 
> > 
> > Well SDL isn't exposed to the network directly - to access the monitor
> > via the SDL console, you'd need to first access the X server 
> > desktop in
> > question. Unprivileged local users, or remote user can't 
> > typically get 
> > access to X desktop of the person who started the VM, so its 
> > not neccessary
> > to disable it.
> 
> What about the unprivileged local user using the X desktop?

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.

> > The console enables the users to map the virtual serial port 
> > onto a physical
> > device. Not a huge issue, but still basically a privilege 
> > escalation because
> > it lets users access hardware they'd not otherwise be able to.
> 
> ?? 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.

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

Regards,
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:28 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 [this message]
2007-03-27 22:40         ` Christian Limpach
2007-03-27 22:47           ` Daniel P. Berrange
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=20070327222851.GE3126@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.