On Tue, Mar 27, 2007 at 02:32:00PM -0700, Christian Limpach wrote:
> > From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx]
> >
> > 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 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home