Re: [PATCH RFC 0/6] qemu-xen-trad: sasl: add SASL support to VNC

[Simon Waterman <watermansrdev@gmail.com>]

On 16/05/17 14:28, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH RFC 0/6] qemu-xen-trad: sasl: add SASL support to VNC"):
>> On 16/05/17 14:16, Ian Jackson wrote:
>>> Simon: What is stopping you moving to a modern version of qemu ?
>> I think from his previous query, it was the fact that there is no
>> suitable stubdom for qemu-upstream.
> Hrm.  I think fixing this is probably a better approach.  Although it
> seems likely to be more involved, it would have better overall
> viability.  Another stopgap would be to use a proxy somewhere to do
> the SASL etc.
>
> Ian.
It's not the QEMU in the stubdom that would need to be newer
but rather the one that's spawned in domain-0 to provide the
VNC backend when you use an IOEMU stubdom.  As I understand
it this also needs to be qemu-xen-traditional but maybe
I've got that wrong?

I agree entirely that enabling upstream QEMU to be used
here would be a better approach and that might be easier
than getting it running inside the stubdom itself.

Maybe I could look into that if it's not already supported.

The port itself is pretty simple.  The biggest change is
probably the refactor of definitions into the header.  I
think it should be relatively easy to verify it's
correctness but I get the point about maintenance of
older versions of qemu-xen-traditional needing different
patches if there was a vulnerability in QEMU VNC.

I think it would be nice to have a better set of options
for authenticating VNC than a fixed shared password and
with SASL you can do GSSAPI, LDAP and a host of others.

To be honest I'm not sure how much it would be used generally.
You can get most of the same benefits using an SSH tunnel
but then again you've got to get that config correct to
keep your domain-0 secure and the client setup is a bit
more fiddly.

In it's favour, there are quite a few VNC clients with
SASL support built-in including virt-viewer and anything
based upon gtk-vnc.  I submitted a patch to libvncserver
so that it's available in Guacamole too.

Has any thought been put into running the VNC server in
the stubdom itself?  That might be nice as VNC access
would be possible without access to the domain-0 at all.
It might help with the 'rebootable' domain-0 work too as
VNC connections wouldn't drop when the domain-0 is restarted.

Thanks for considering the patch, whether it goes in
or not.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel