From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: RE: [Xen-staging] [xen-unstable] hvm: Remove access to QEMU monitor inVNC server Date: Tue, 27 Mar 2007 23:47:24 +0100 Message-ID: <20070327224724.GF3126@redhat.com> References: <200703271524.l2RFOMNg003926@latara.uk.xensource.com> <0326530267625D42A4E36594FDD0D1432EBA8A@exchpamain.ad.xensource.com> <20070327211826.GD3126@redhat.com> <0326530267625D42A4E36594FDD0D1432EBAA7@exchpamain.ad.xensource.com> <20070327222851.GE3126@redhat.com> <0326530267625D42A4E36594FDD0D1432EBB1F@exchpamain.ad.xensource.com> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <0326530267625D42A4E36594FDD0D1432EBB1F@exchpamain.ad.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christian Limpach Cc: xen-staging@lists.xensource.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 -=|