Someone pointed out that it''s not possible to configure encrypted vnc
via xl, while it is possible via xm. This is obviously quite nice to
have if you are logging in as root...
The following is my initial attempt but TBH I''m not sure if this is
presenting the correct interface at either the libxl or xl level. Since
I don''t actually use this stuff myself I''m finding it a bit
hard to
judge how much flexibility is needed or even what the right names/terms
for things are. Opinions?
Enabling basic TLS is simple enough but the x509 auth stuff is more
complicated and I expect a bit of a docs tarpit (references below).
I didn''t do upstream qemu, stub qemu or vfb yet (there''s a
bunch of
yacks in this regard, not least factoring out the duplication). Upstream
qemu supports a few more options (e.g. sasl, see qemu(1)). SASL adds
more complexity since it can be used with or without the x509 options
depending on your needs and the specific SASL config you have in place
for qemu which complexifies all the interfaces.
Notes to be turned into docs in the final version:
Clients seem thin on the ground, neither xtightvncviewer nor vnc4viewer
support TLS. gvncviewer does seem to support all options.
http://virt-manager.org/page/RemoteTLS has a bit of stuff and some
useful links. In particular to http://libvirt.org/remote.html which has
a reasonable description of how to generate appropriate certs. On the
server I ended up with:
/etc/xen/vnc/server-cert.pem
/etc/xen/vnc/ca-cert.pem
/etc/xen/vnc/server-key.pem
while on the client:
.pki/CA/cacert.pem
.pki/gvncviewer/clientcert.pem
.pki/gvncviewer/private/clientkey.pem
diff -r 3a9f9ba40be2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl.h Thu Dec 15 11:59:28 2011 +0000
@@ -644,6 +644,7 @@ const char *libxl_xen_script_dir_path(vo
const char *libxl_lock_dir_path(void);
const char *libxl_run_dir_path(void);
const char *libxl_xenpaging_dir_path(void);
+const char *libxl_vnc_cert_dir_path(void);
/* misc */
int libxl_fd_set_cloexec(int fd);
diff -r 3a9f9ba40be2 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl_dm.c Thu Dec 15 11:59:28 2011 +0000
@@ -121,6 +121,29 @@ static char ** libxl__build_device_model
}
if (info->vncpasswd && (info->vncpasswd[0] !=
''\0''))
vncarg = libxl__sprintf(gc, "%s,password", vncarg);
+ switch (info->vnctls) {
+ case LIBXL_VNC_TLSMODE_NONE:
+ fprintf(stderr, "no vnc tls\n");
+ break;
+ case LIBXL_VNC_TLSMODE_TLS:
+ vncarg = libxl__sprintf(gc, "%s,tls", vncarg);
+ break;
+ case LIBXL_VNC_TLSMODE_X509:
+ vncarg = libxl__sprintf(gc, "%s,tls,x509=%s",
+ vncarg,
+ info->vnccert
+ ? info->vnccert
+ : libxl_vnc_cert_dir_path());
+ break;
+ case LIBXL_VNC_TLSMODE_X509VERIFY:
+ vncarg = libxl__sprintf(gc, "%s,tls,x509verify=%s",
+ vncarg,
+ info->vnccert
+ ? info->vnccert
+ : libxl_vnc_cert_dir_path());
+ break;
+ }
+
flexarray_append(dm_args, "-vnc");
flexarray_append(dm_args, vncarg);
@@ -990,6 +1013,8 @@ static int libxl__build_xenpv_qemu_args(
info->vnclisten = libxl__strdup(gc, vfb->vnclisten);
info->vncdisplay = vfb->vncdisplay;
info->vncunused = vfb->vncunused;
+ //info->vnctls = vfb->vnctls;
+ //info->vnccert = vfb->vnccert;
if (vfb->vncpasswd)
info->vncpasswd = vfb->vncpasswd;
if (vfb->keymap)
diff -r 3a9f9ba40be2 tools/libxl/libxl_paths.c
--- a/tools/libxl/libxl_paths.c Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl_paths.c Thu Dec 15 11:59:28 2011 +0000
@@ -75,6 +75,11 @@ const char *libxl_xenpaging_dir_path(voi
return XEN_PAGING_DIR;
}
+const char *libxl_vnc_cert_dir_path(void)
+{
+ return XEN_CONFIG_DIR "/vnc";
+}
+
/*
* Local variables:
* mode: C
diff -r 3a9f9ba40be2 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl_types.idl Thu Dec 15 11:59:28 2011 +0000
@@ -92,6 +92,13 @@ libxl_tsc_mode = Enumeration("tsc_mode",
(3, "native_paravirt"),
])
+libxl_vnc_tlsmode = Enumeration("vnc_tlsmode", [
+ (0, "none"),
+ (1, "tls"),
+ (2, "x509"),
+ (3, "x509verify"),
+ ])
+
#
# Complex libxl types
#
@@ -220,6 +227,8 @@ libxl_device_model_info = Struct("device
("vncpasswd", string, False, "the VNC
password"),
("vncdisplay", integer, False, "set VNC
display number"),
("vncunused", bool, False, "try to find
an unused port for the VNC server"),
+ ("vnctls", libxl_vnc_tlsmode),
+ ("vnccert", string, False, "Path to VNC
TLS certificates"),
("keymap", string, False, "set keyboard
layout, default is en-us keyboard"),
("sdl", bool, False, "sdl enabled
or disabled"),
("opengl", bool, False, "opengl
enabled or disabled (if enabled requires sdl enabled)"),
diff -r 3a9f9ba40be2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c Thu Dec 15 11:59:28 2011 +0000
@@ -1183,6 +1183,18 @@ skip_vfb:
dm_info->vncdisplay = l;
if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
dm_info->vncunused = l;
+ if (!xlu_cfg_get_string (config, "vnctls", &buf, 0)) {
+ fprintf(stderr, "VNC: %s\n", buf);
+ if (libxl_vnc_tlsmode_from_string(buf, &dm_info->vnctls)) {
+ fprintf(stderr, "ERROR: invalid value \"%s\" for
\"vnctls\"\n",
+ buf);
+ exit (1);
+ }
+ } else {
+ fprintf(stderr, "!VNC: %s\n", buf);
+ exit(1);
+ }
+ xlu_cfg_replace_string (config, "vnccert",
&dm_info->vnccert, 0);
xlu_cfg_replace_string (config, "keymap",
&dm_info->keymap, 0);
if (!xlu_cfg_get_long (config, "sdl", &l, 0))
dm_info->sdl = l;
Pasi Kärkkäinen
2011-Dec-15 13:29 UTC
Re: [RFC] xl: support configuration of encrypted VNC
On Thu, Dec 15, 2011 at 12:25:36PM +0000, Ian Campbell wrote:> Someone pointed out that it''s not possible to configure encrypted vnc > via xl, while it is possible via xm. This is obviously quite nice to > have if you are logging in as root... > > The following is my initial attempt but TBH I''m not sure if this is > presenting the correct interface at either the libxl or xl level. Since > I don''t actually use this stuff myself I''m finding it a bit hard to > judge how much flexibility is needed or even what the right names/terms > for things are. Opinions? > > Enabling basic TLS is simple enough but the x509 auth stuff is more > complicated and I expect a bit of a docs tarpit (references below). > > I didn''t do upstream qemu, stub qemu or vfb yet (there''s a bunch of > yacks in this regard, not least factoring out the duplication). Upstream > qemu supports a few more options (e.g. sasl, see qemu(1)). SASL adds > more complexity since it can be used with or without the x509 options > depending on your needs and the specific SASL config you have in place > for qemu which complexifies all the interfaces. > > Notes to be turned into docs in the final version: > > Clients seem thin on the ground, neither xtightvncviewer nor vnc4viewer > support TLS. gvncviewer does seem to support all options. >I guess it makes sense to mention ''virt-viewer'' in this list aswell.. -- Pasi> http://virt-manager.org/page/RemoteTLS has a bit of stuff and some > useful links. In particular to http://libvirt.org/remote.html which has > a reasonable description of how to generate appropriate certs. On the > server I ended up with: >
On Thu, 2011-12-15 at 13:29 +0000, Pasi Kärkkäinen wrote:> On Thu, Dec 15, 2011 at 12:25:36PM +0000, Ian Campbell wrote: > > Someone pointed out that it's not possible to configure encrypted vnc > > via xl, while it is possible via xm. This is obviously quite nice to > > have if you are logging in as root... > > > > The following is my initial attempt but TBH I'm not sure if this is > > presenting the correct interface at either the libxl or xl level. Since > > I don't actually use this stuff myself I'm finding it a bit hard to > > judge how much flexibility is needed or even what the right names/terms > > for things are. Opinions? > > > > Enabling basic TLS is simple enough but the x509 auth stuff is more > > complicated and I expect a bit of a docs tarpit (references below). > > > > I didn't do upstream qemu, stub qemu or vfb yet (there's a bunch of > > yacks in this regard, not least factoring out the duplication). Upstream > > qemu supports a few more options (e.g. sasl, see qemu(1)). SASL adds > > more complexity since it can be used with or without the x509 options > > depending on your needs and the specific SASL config you have in place > > for qemu which complexifies all the interfaces. > > > > Notes to be turned into docs in the final version: > > > > Clients seem thin on the ground, neither xtightvncviewer nor vnc4viewer > > support TLS. gvncviewer does seem to support all options. > > > > I guess it makes sense to mention 'virt-viewer' in this list aswell..I couldn't figure out how to make it speak direct to a vnc port as opposed to needing libvirt and all that.> > -- Pasi > > > http://virt-manager.org/page/RemoteTLS has a bit of stuff and some > > useful links. In particular to http://libvirt.org/remote.html which has > > a reasonable description of how to generate appropriate certs. On the > > server I ended up with: > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of
encrypted VNC"):> Someone pointed out that it''s not possible to configure encrypted
vnc
> via xl, while it is possible via xm. This is obviously quite nice to
> have if you are logging in as root...
>
> The following is my initial attempt but TBH I''m not sure if this
is
> presenting the correct interface at either the libxl or xl level. Since
> I don''t actually use this stuff myself I''m finding it a
bit hard to
> judge how much flexibility is needed or even what the right names/terms
> for things are. Opinions?
What is the security implication of the path with the certificates ?
Is it that only clients with that particular certificate can connect ?
> + if (!xlu_cfg_get_string (config, "vnctls", &buf, 0))
{
> + fprintf(stderr, "VNC: %s\n", buf);
> + if (libxl_vnc_tlsmode_from_string(buf,
&dm_info->vnctls)) {
> + fprintf(stderr, "ERROR: invalid value
\"%s\" for \"vnctls\"\n",
> + buf);
> + exit (1);
> + }
> + } else {
> + fprintf(stderr, "!VNC: %s\n", buf);
> + exit(1);
> + }
This is a bit odd. If you don''t say "vnctls" in your config
file, the
config parser just exits ?
Ian.
On Tue, 2011-12-20 at 18:25 +0000, Ian Jackson wrote:> Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of encrypted VNC"): > > Someone pointed out that it''s not possible to configure encrypted vnc > > via xl, while it is possible via xm. This is obviously quite nice to > > have if you are logging in as root... > > > > The following is my initial attempt but TBH I''m not sure if this is > > presenting the correct interface at either the libxl or xl level. Since > > I don''t actually use this stuff myself I''m finding it a bit hard to > > judge how much flexibility is needed or even what the right names/terms > > for things are. Opinions? > > What is the security implication of the path with the certificates ? > Is it that only clients with that particular certificate can connect ?This option corresponds to the path given to the x509 or x509verify option to qemu''s -vnc. The man page isn''t totally clear about what goes on but AIUI it will look for a CA cert under here and only accept clients with a cert signed by that CA. There must surely (?!) be a way to allow you to certify two customers but only allow them to connect to their own VM but I don''t see what it is, I don''t seem to have ended up with either half of a client cert under that path yet all three options worked for me. Aha, http://libvirt.org/remote.html suggests that the client certs DN can be checked against an access control list. Upstream qemu documents an "acl" command you must use via the monitor to allow the DN. qemu-xen seems to predate this support.> > > + if (!xlu_cfg_get_string (config, "vnctls", &buf, 0)) { > > + fprintf(stderr, "VNC: %s\n", buf); > > + if (libxl_vnc_tlsmode_from_string(buf, &dm_info->vnctls)) { > > + fprintf(stderr, "ERROR: invalid value \"%s\" for \"vnctls\"\n", > > + buf); > > + exit (1); > > + } > > + } else { > > + fprintf(stderr, "!VNC: %s\n", buf); > > + exit(1); > > + } > > This is a bit odd. If you don''t say "vnctls" in your config file, the > config parser just exits ?Err. that may have been some debug cruft to check I was really passing the right option when it didn''t seem to be working... Ian.
Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of
encrypted VNC"):> The following is my initial attempt but TBH I''m not sure if this
is
> presenting the correct interface at either the libxl or xl level. Since
> I don''t actually use this stuff myself I''m finding it a
bit hard to
> judge how much flexibility is needed or even what the right names/terms
> for things are. Opinions?
I think this will do, modulo the comments in the thread and your
intent to add some docs. Is a fresh patch going to be forthcoming ?
Ian.
On Thu, 2012-01-05 at 14:30 +0000, Ian Jackson wrote:> Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of encrypted VNC"): > > The following is my initial attempt but TBH I''m not sure if this is > > presenting the correct interface at either the libxl or xl level. Since > > I don''t actually use this stuff myself I''m finding it a bit hard to > > judge how much flexibility is needed or even what the right names/terms > > for things are. Opinions? > > I think this will do, modulo the comments in the thread and your > intent to add some docs. Is a fresh patch going to be forthcoming ?That''s my intention, although it is behind a pretty big series in my queue which I''d like to flush first. Ian.