| Message ID | 1345807781-23452-1-git-send-email-asias.hejun@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 08/24/2012 02:29 PM, Asias He wrote: > It is useful to run a X program in guest and display it on host. > > 1) Make host's x server listen to localhost:6000 > host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ > UNIX-CONNECT:/tmp/.X11-unix/X0 > > 2) Start the guest and run X program > host_shell$ lkvm run -k /boot/bzImage > guest_shell$ xlogo > Note, this is insecure, don't do this with untrusted guests.
On Tue, Sep 4, 2012 at 9:07 PM, Avi Kivity <avi@redhat.com> wrote: > On 08/24/2012 02:29 PM, Asias He wrote: >> It is useful to run a X program in guest and display it on host. >> >> 1) Make host's x server listen to localhost:6000 >> host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ >> UNIX-CONNECT:/tmp/.X11-unix/X0 >> >> 2) Start the guest and run X program >> host_shell$ lkvm run -k /boot/bzImage >> guest_shell$ xlogo >> > > Note, this is insecure, don't do this with untrusted guests. In this use case, the user on the host side should trust the guest. Btw, any attack the untrusted guests can do with the X port which host listens?
On 09/05/2012 09:03 AM, Asias He wrote: > On Tue, Sep 4, 2012 at 9:07 PM, Avi Kivity <avi@redhat.com> wrote: >> On 08/24/2012 02:29 PM, Asias He wrote: >>> It is useful to run a X program in guest and display it on host. >>> >>> 1) Make host's x server listen to localhost:6000 >>> host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ >>> UNIX-CONNECT:/tmp/.X11-unix/X0 >>> >>> 2) Start the guest and run X program >>> host_shell$ lkvm run -k /boot/bzImage >>> guest_shell$ xlogo >>> >> >> Note, this is insecure, don't do this with untrusted guests. > > In this use case, the user on the host side should trust the guest. > > Btw, any attack the untrusted guests can do with the X port which host listens? Steal the entire display, record user keystrokes, present false information. btw, how did it work? The you need the xauth cookie for this to work, or disable authentication.
On 08/24/2012 02:29 PM, Asias He wrote: >> It is useful to run a X program in guest and display it on host. >> >> 1) Make host's x server listen to localhost:6000 >> host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ >> UNIX-CONNECT:/tmp/.X11-unix/X0 >> >> 2) Start the guest and run X program >> host_shell$ lkvm run -k /boot/bzImage >> guest_shell$ xlogo On Tue, Sep 4, 2012 at 4:07 PM, Avi Kivity <avi@redhat.com> wrote: > Note, this is insecure, don't do this with untrusted guests. Asias, can we add a command line argument that enables this? It'd be safer to keep it disabled by default. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Pekka Enberg <penberg@kernel.org> wrote: > On 08/24/2012 02:29 PM, Asias He wrote: > >> It is useful to run a X program in guest and display it on host. > >> > >> 1) Make host's x server listen to localhost:6000 > >> host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ > >> UNIX-CONNECT:/tmp/.X11-unix/X0 > >> > >> 2) Start the guest and run X program > >> host_shell$ lkvm run -k /boot/bzImage > >> guest_shell$ xlogo > > On Tue, Sep 4, 2012 at 4:07 PM, Avi Kivity <avi@redhat.com> wrote: > > Note, this is insecure, don't do this with untrusted guests. > > Asias, can we add a command line argument that enables this? > It'd be safer to keep it disabled by default. It might also be prudent to name the option in a way that signals that the user of it understands the security implications: --X11-trusted-guest 1 or so. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 5, 2012 at 4:00 PM, Pekka Enberg <penberg@kernel.org> wrote: > On 08/24/2012 02:29 PM, Asias He wrote: >>> It is useful to run a X program in guest and display it on host. >>> >>> 1) Make host's x server listen to localhost:6000 >>> host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ >>> UNIX-CONNECT:/tmp/.X11-unix/X0 >>> >>> 2) Start the guest and run X program >>> host_shell$ lkvm run -k /boot/bzImage >>> guest_shell$ xlogo > > On Tue, Sep 4, 2012 at 4:07 PM, Avi Kivity <avi@redhat.com> wrote: >> Note, this is insecure, don't do this with untrusted guests. > > Asias, can we add a command line argument that enables this? It'd be > safer to keep it disabled by default. Step 1) is not started by lkvm, if user does not run the socat cmd in host side, the remote display for guest will not work at all. This patch only set DISPLAY env to host IP. if user runs the socat cmd in host side, even if without the exporting DISPLAY env, the untrusted guest can also do the attack.
On Wed, Sep 5, 2012 at 4:09 PM, Ingo Molnar <mingo@kernel.org> wrote: > > * Pekka Enberg <penberg@kernel.org> wrote: > >> On 08/24/2012 02:29 PM, Asias He wrote: >> >> It is useful to run a X program in guest and display it on host. >> >> >> >> 1) Make host's x server listen to localhost:6000 >> >> host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ >> >> UNIX-CONNECT:/tmp/.X11-unix/X0 >> >> >> >> 2) Start the guest and run X program >> >> host_shell$ lkvm run -k /boot/bzImage >> >> guest_shell$ xlogo >> >> On Tue, Sep 4, 2012 at 4:07 PM, Avi Kivity <avi@redhat.com> wrote: >> > Note, this is insecure, don't do this with untrusted guests. >> >> Asias, can we add a command line argument that enables this? >> It'd be safer to keep it disabled by default. > > It might also be prudent to name the option in a way that > signals that the user of it understands the security > implications: > > --X11-trusted-guest 1 > Yes. If we do something like the socat cmd does in step 1) above in lkvm, we need a option to enable that explicitly.
On Wed, Sep 5, 2012 at 3:56 PM, Avi Kivity <avi@redhat.com> wrote: > On 09/05/2012 09:03 AM, Asias He wrote: >> On Tue, Sep 4, 2012 at 9:07 PM, Avi Kivity <avi@redhat.com> wrote: >>> On 08/24/2012 02:29 PM, Asias He wrote: >>>> It is useful to run a X program in guest and display it on host. >>>> >>>> 1) Make host's x server listen to localhost:6000 >>>> host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ >>>> UNIX-CONNECT:/tmp/.X11-unix/X0 >>>> >>>> 2) Start the guest and run X program >>>> host_shell$ lkvm run -k /boot/bzImage >>>> guest_shell$ xlogo >>>> >>> >>> Note, this is insecure, don't do this with untrusted guests. >> >> In this use case, the user on the host side should trust the guest. >> >> Btw, any attack the untrusted guests can do with the X port which host listens? > > Steal the entire display, record user keystrokes, present false information. OK. > btw, how did it work? The you need the xauth cookie for this to work, > or disable authentication. The trick here is just listening tcp x11 port(only on localhost) and forwarding the tcp x11 data to local socket. The auth sutff should be done by the host side normal X11 setup.
On 09/05/2012 12:19 PM, Asias He wrote: > On Wed, Sep 5, 2012 at 3:56 PM, Avi Kivity <avi@redhat.com> wrote: >> On 09/05/2012 09:03 AM, Asias He wrote: >>> On Tue, Sep 4, 2012 at 9:07 PM, Avi Kivity <avi@redhat.com> wrote: >>>> On 08/24/2012 02:29 PM, Asias He wrote: >>>>> It is useful to run a X program in guest and display it on host. >>>>> >>>>> 1) Make host's x server listen to localhost:6000 >>>>> host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ >>>>> UNIX-CONNECT:/tmp/.X11-unix/X0 >>>>> >>>>> 2) Start the guest and run X program >>>>> host_shell$ lkvm run -k /boot/bzImage >>>>> guest_shell$ xlogo >>>>> >>>> >>>> Note, this is insecure, don't do this with untrusted guests. >>> >>> In this use case, the user on the host side should trust the guest. >>> >>> Btw, any attack the untrusted guests can do with the X port which host listens? >> >> Steal the entire display, record user keystrokes, present false information. > > OK. > >> btw, how did it work? The you need the xauth cookie for this to work, >> or disable authentication. > > The trick here is just listening tcp x11 port(only on localhost) and > forwarding the tcp x11 data to local socket. > The auth sutff should be done by the host side normal X11 setup. > Ok. Then the socat command not only exposes the display to the guest, but also to any local process with access to localhost:6000.
On Wed, Sep 5, 2012 at 5:29 PM, Avi Kivity <avi@redhat.com> wrote: > On 09/05/2012 12:19 PM, Asias He wrote: >> On Wed, Sep 5, 2012 at 3:56 PM, Avi Kivity <avi@redhat.com> wrote: >>> On 09/05/2012 09:03 AM, Asias He wrote: >>>> On Tue, Sep 4, 2012 at 9:07 PM, Avi Kivity <avi@redhat.com> wrote: >>>>> On 08/24/2012 02:29 PM, Asias He wrote: >>>>>> It is useful to run a X program in guest and display it on host. >>>>>> >>>>>> 1) Make host's x server listen to localhost:6000 >>>>>> host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ >>>>>> UNIX-CONNECT:/tmp/.X11-unix/X0 >>>>>> >>>>>> 2) Start the guest and run X program >>>>>> host_shell$ lkvm run -k /boot/bzImage >>>>>> guest_shell$ xlogo >>>>>> >>>>> >>>>> Note, this is insecure, don't do this with untrusted guests. >>>> >>>> In this use case, the user on the host side should trust the guest. >>>> >>>> Btw, any attack the untrusted guests can do with the X port which host listens? >>> >>> Steal the entire display, record user keystrokes, present false information. >> >> OK. >> >>> btw, how did it work? The you need the xauth cookie for this to work, >>> or disable authentication. >> >> The trick here is just listening tcp x11 port(only on localhost) and >> forwarding the tcp x11 data to local socket. >> The auth sutff should be done by the host side normal X11 setup. >> > > Ok. Then the socat command not only exposes the display to the guest, > but also to any local process with access to localhost:6000. Yes. It is a trick for people with 'Xorg -nolisten tcp' enabled.
On 09/05/2012 12:46 PM, Asias He wrote: >> Ok. Then the socat command not only exposes the display to the guest, >> but also to any local process with access to localhost:6000. > > Yes. It is a trick for people with 'Xorg -nolisten tcp' enabled. Which is hopefully everyone.
On Wed, Sep 5, 2012 at 5:53 PM, Avi Kivity <avi@redhat.com> wrote: > On 09/05/2012 12:46 PM, Asias He wrote: >>> Ok. Then the socat command not only exposes the display to the guest, >>> but also to any local process with access to localhost:6000. >> >> Yes. It is a trick for people with 'Xorg -nolisten tcp' enabled. > > Which is hopefully everyone. Yup. That's why I want the socat trick ;-d
On 09/05/2012 01:14 PM, Asias He wrote: > On Wed, Sep 5, 2012 at 5:53 PM, Avi Kivity <avi@redhat.com> wrote: >> On 09/05/2012 12:46 PM, Asias He wrote: >>>> Ok. Then the socat command not only exposes the display to the guest, >>>> but also to any local process with access to localhost:6000. >>> >>> Yes. It is a trick for people with 'Xorg -nolisten tcp' enabled. >> >> Which is hopefully everyone. > > Yup. That's why I want the socat trick ;-d No, it's horribly insecure. One option is to generate a temporary keypair and use ssh. Or you can make the guest talk to an internal unix-domain socket, tunnel that through virtio-serial, terminate virtio-serial in lkvm, and direct it towards the local X socket. It's more work than exposing X11 via tcp, but if the user said -nolisten tcp, you must respect it.
On Wed, Sep 5, 2012 at 7:56 PM, Avi Kivity <avi@redhat.com> wrote: > On 09/05/2012 01:14 PM, Asias He wrote: >> On Wed, Sep 5, 2012 at 5:53 PM, Avi Kivity <avi@redhat.com> wrote: >>> On 09/05/2012 12:46 PM, Asias He wrote: >>>>> Ok. Then the socat command not only exposes the display to the guest, >>>>> but also to any local process with access to localhost:6000. >>>> >>>> Yes. It is a trick for people with 'Xorg -nolisten tcp' enabled. >>> >>> Which is hopefully everyone. >> >> Yup. That's why I want the socat trick ;-d > > No, it's horribly insecure. > > One option is to generate a temporary keypair and use ssh. ssh X11 forwarding need a ssh connection from host to guest. This requires a port forwarding from host to guest. lkvm's user mode network does not support this forwarding atm. > Or you can > make the guest talk to an internal unix-domain socket, tunnel that > through virtio-serial, terminate virtio-serial in lkvm, and direct it > towards the local X socket. Doesn't this require some user agent or config modification to the guest? Instead using a non-standard transport like virito-serial, maybe we can listen guest's x11 tcp data and forward ( may need some kind of conversion) to the local X socket. > It's more work than exposing X11 via tcp, > but if the user said -nolisten tcp, you must respect it.
On 09/06/2012 06:32 AM, Asias He wrote: > On Wed, Sep 5, 2012 at 7:56 PM, Avi Kivity <avi@redhat.com> wrote: >> On 09/05/2012 01:14 PM, Asias He wrote: >>> On Wed, Sep 5, 2012 at 5:53 PM, Avi Kivity <avi@redhat.com> wrote: >>>> On 09/05/2012 12:46 PM, Asias He wrote: >>>>>> Ok. Then the socat command not only exposes the display to the guest, >>>>>> but also to any local process with access to localhost:6000. >>>>> >>>>> Yes. It is a trick for people with 'Xorg -nolisten tcp' enabled. >>>> >>>> Which is hopefully everyone. >>> >>> Yup. That's why I want the socat trick ;-d >> >> No, it's horribly insecure. >> >> One option is to generate a temporary keypair and use ssh. > > ssh X11 forwarding need a ssh connection from host to guest. This > requires a port forwarding from host to guest. > lkvm's user mode network does not support this forwarding atm. That's actually a very useful feature. > >> Or you can >> make the guest talk to an internal unix-domain socket, tunnel that >> through virtio-serial, terminate virtio-serial in lkvm, and direct it >> towards the local X socket. > > Doesn't this require some user agent or config modification to the guest? It does, a daemon that listens locally and forwards data over virtio-serial. But you build your own initrd anyway, don't you? Another option is ppp-over-virtio-serial. > Instead using a non-standard transport like virito-serial, maybe we > can listen guest's x11 tcp data and forward ( may need some kind of > conversion) to the local X socket. Sure, you can terminate the connection in lkvm (in effect lkvm becomes an X server) and forward all traffic to the local unix-domain socket.
On Thu, Sep 6, 2012 at 3:59 PM, Avi Kivity <avi@redhat.com> wrote: > On 09/06/2012 06:32 AM, Asias He wrote: >> On Wed, Sep 5, 2012 at 7:56 PM, Avi Kivity <avi@redhat.com> wrote: >>> On 09/05/2012 01:14 PM, Asias He wrote: >>>> On Wed, Sep 5, 2012 at 5:53 PM, Avi Kivity <avi@redhat.com> wrote: >>>>> On 09/05/2012 12:46 PM, Asias He wrote: >>>>>>> Ok. Then the socat command not only exposes the display to the guest, >>>>>>> but also to any local process with access to localhost:6000. >>>>>> >>>>>> Yes. It is a trick for people with 'Xorg -nolisten tcp' enabled. >>>>> >>>>> Which is hopefully everyone. >>>> >>>> Yup. That's why I want the socat trick ;-d >>> >>> No, it's horribly insecure. >>> >>> One option is to generate a temporary keypair and use ssh. >> >> ssh X11 forwarding need a ssh connection from host to guest. This >> requires a port forwarding from host to guest. >> lkvm's user mode network does not support this forwarding atm. > > That's actually a very useful feature. Yes, exactly. > >> >>> Or you can >>> make the guest talk to an internal unix-domain socket, tunnel that >>> through virtio-serial, terminate virtio-serial in lkvm, and direct it >>> towards the local X socket. >> >> Doesn't this require some user agent or config modification to the guest? > > It does, a daemon that listens locally and forwards data over > virtio-serial. But you build your own initrd anyway, don't you? Using our custom init file is one use case. User may use distro disk image as guest also. > Another option is ppp-over-virtio-serial. Seems this still uses tcp where the link layer changes from ethernet to serial. >> Instead using a non-standard transport like virito-serial, maybe we >> can listen guest's x11 tcp data and forward ( may need some kind of >> conversion) to the local X socket. > > Sure, you can terminate the connection in lkvm (in effect lkvm becomes > an X server) and forward all traffic to the local unix-domain socket.
On 09/10/2012 04:26 AM, Asias He wrote: >> >>> >>>> Or you can >>>> make the guest talk to an internal unix-domain socket, tunnel that >>>> through virtio-serial, terminate virtio-serial in lkvm, and direct it >>>> towards the local X socket. >>> >>> Doesn't this require some user agent or config modification to the guest? >> >> It does, a daemon that listens locally and forwards data over >> virtio-serial. But you build your own initrd anyway, don't you? > > Using our custom init file is one use case. User may use distro disk > image as guest also. We could push it into the distros, it should be useful for qemu as well. This could be done even more properly by adding support for virtio-serial in X itself (is anything really needed on the client side?) The only problem is that it is insecure, but maybe http://www.nsa.gov/research/_files/selinux/papers/x11/t1.shtml can help. I don't know if it's integrated yet. > >> Another option is ppp-over-virtio-serial. > > Seems this still uses tcp where the link layer changes from ethernet to serial. Right, you have to terminate it on the host side without routing.
diff --git a/tools/kvm/guest/init.c b/tools/kvm/guest/init.c index 6a2e1cd..44e7db8 100644 --- a/tools/kvm/guest/init.c +++ b/tools/kvm/guest/init.c @@ -12,7 +12,7 @@ static int run_process(char *filename) { char *new_argv[] = { filename, NULL }; - char *new_env[] = { "TERM=linux", NULL }; + char *new_env[] = { "TERM=linux", "DISPLAY=192.168.33.1:0", NULL }; return execve(filename, new_argv, new_env); }
It is useful to run a X program in guest and display it on host. 1) Make host's x server listen to localhost:6000 host_shell$ socat -d -d TCP-LISTEN:6000,fork,bind=localhost \ UNIX-CONNECT:/tmp/.X11-unix/X0 2) Start the guest and run X program host_shell$ lkvm run -k /boot/bzImage guest_shell$ xlogo Signed-off-by: Asias He <asias.hejun@gmail.com> --- tools/kvm/guest/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)