Implement a ''vnclisten'' option to limit the interface that the VNC server from qemu listens on. This leaves the default behavior as listening on all interfaces. Signed-off-by: Jeremy Katz <katzj@redhat.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 2006-09-02 at 12:55 -0400, Jeremy Katz wrote:> Implement a ''vnclisten'' option to limit the interface that the VNC > server from qemu listens on. This leaves the default behavior as > listening on all interfaces. > > Signed-off-by: Jeremy Katz <katzj@redhat.com>danpb said something about this and it reminded me I never saw any feedback.... Bueller? :-) Jeremy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Sep 27, 2006 at 03:36:16PM -0400, Jeremy Katz wrote:> On Sat, 2006-09-02 at 12:55 -0400, Jeremy Katz wrote: > > Implement a ''vnclisten'' option to limit the interface that the VNC > > server from qemu listens on. This leaves the default behavior as > > listening on all interfaces. > > > > Signed-off-by: Jeremy Katz <katzj@redhat.com> > > danpb said something about this and it reminded me I never saw any > feedback.... Bueller? :-)IMHO, we should only listen on 127.0.0.1 by default - particularly since the Xen 3.0.3 release isn''t going to have password authentication on the VNC servers yet :-( It''ll be all too easy for someone to turn on VNC in the guest config & not realize they just opened themselves up to any person on the network by default. That kind of default insecure behaviour is best left in the Windows world 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@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2006-09-27 at 20:42 +0100, Daniel P. Berrange wrote:> On Wed, Sep 27, 2006 at 03:36:16PM -0400, Jeremy Katz wrote: > > On Sat, 2006-09-02 at 12:55 -0400, Jeremy Katz wrote: > > > Implement a ''vnclisten'' option to limit the interface that the VNC > > > server from qemu listens on. This leaves the default behavior as > > > listening on all interfaces. > > > > > > Signed-off-by: Jeremy Katz <katzj@redhat.com> > > > > danpb said something about this and it reminded me I never saw any > > feedback.... Bueller? :-) > > IMHO, we should only listen on 127.0.0.1 by default - particularly since > the Xen 3.0.3 release isn''t going to have password authentication on the > VNC servers yet :-( It''ll be all too easy for someone to turn on VNC > in the guest config & not realize they just opened themselves up to any > person on the network by default. That kind of default insecure behaviour > is best left in the Windows worldI don''t necessarily disagree, but changing the semantics like that felt a little bit ugly to me -- it definitely leads to a case where going from 3.0.2 -> 3.0.3 would break configurations users were actively using. Jeremy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Sep 27, 2006 at 03:57:31PM -0400, Jeremy Katz wrote:> On Wed, 2006-09-27 at 20:42 +0100, Daniel P. Berrange wrote: > > On Wed, Sep 27, 2006 at 03:36:16PM -0400, Jeremy Katz wrote: > > > On Sat, 2006-09-02 at 12:55 -0400, Jeremy Katz wrote: > > > > Implement a ''vnclisten'' option to limit the interface that the VNC > > > > server from qemu listens on. This leaves the default behavior as > > > > listening on all interfaces. > > > > > > > > Signed-off-by: Jeremy Katz <katzj@redhat.com> > > > > > > danpb said something about this and it reminded me I never saw any > > > feedback.... Bueller? :-) > > > > IMHO, we should only listen on 127.0.0.1 by default - particularly since > > the Xen 3.0.3 release isn''t going to have password authentication on the > > VNC servers yet :-( It''ll be all too easy for someone to turn on VNC > > in the guest config & not realize they just opened themselves up to any > > person on the network by default. That kind of default insecure behaviour > > is best left in the Windows world > > I don''t necessarily disagree, but changing the semantics like that felt > a little bit ugly to me -- it definitely leads to a case where going > from 3.0.2 -> 3.0.3 would break configurations users were actively > using.It is a painful problem I agree, but I think the security benefit is worth the pain of breaking user''s existing configs. Its not a difficult task for users to re-enable the wide-open-to-anyone config if they really do need it. 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@lists.xensource.com http://lists.xensource.com/xen-devel
> > > IMHO, we should only listen on 127.0.0.1 by default -particularly> since > > > the Xen 3.0.3 release isn''t going to have password authenticationon> the > > > VNC servers yet :-( It''ll be all too easy for someone to turn onVNC> > > in the guest config & not realize they just opened themselves upto any> > > person on the network by default. That kind of default insecure > behaviour > > > is best left in the Windows world > > > > I don''t necessarily disagree, but changing the semantics like thatfelt> > a little bit ugly to me -- it definitely leads to a case where going > > from 3.0.2 -> 3.0.3 would break configurations users were actively > > using. > > It is a painful problem I agree, but I think the security benefit isworth> the pain of breaking user''s existing configs. Its not a difficult taskfor> users to re-enable the wide-open-to-anyone config if they really doneed> it.I agree too: we should listen on 127.0.0.1 by default. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Sep 27, 2006 at 09:40:57PM +0100, Ian Pratt wrote:> > > > IMHO, we should only listen on 127.0.0.1 by default - > particularly > > since > > > > the Xen 3.0.3 release isn''t going to have password authentication > on > > the > > > > VNC servers yet :-( It''ll be all too easy for someone to turn on > VNC > > > > in the guest config & not realize they just opened themselves up > to any > > > > person on the network by default. That kind of default insecure > > behaviour > > > > is best left in the Windows world > > > > > > I don''t necessarily disagree, but changing the semantics like that > felt > > > a little bit ugly to me -- it definitely leads to a case where going > > > from 3.0.2 -> 3.0.3 would break configurations users were actively > > > using. > > > > It is a painful problem I agree, but I think the security benefit is > worth > > the pain of breaking user''s existing configs. Its not a difficult task > for > > users to re-enable the wide-open-to-anyone config if they really do > need > > it. > > I agree too: we should listen on 127.0.0.1 by default.Ok, attached is an adaptation of Jeremy''s initial patch to do this. The logic for determining which interface to listen on goes like this: - If ''vnclisten'' is set in guest config, use that (can use 0.0.0.0 to indicate all interfaces) - If ''vnc-listen'' is set in /etc/xen/xend-config.sxp, use that (again can set it to 0.0.0.0 to listen on all interfaces by default) - Else use 127.0.0.1 So, this makes VNC local only by default using 127.0.0.1. Anyone who wants the old behaviour can just change xend-config.sxp setting... (vnc-listen ''0.0.0.0'') ...which will affect all guests without an explicit setting. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
> Ok, attached is an adaptation of Jeremy''s initial patch to do this. > > The logic for determining which interface to listen on goes like this: > > - If ''vnclisten'' is set in guest config, use that (can use 0.0.0.0 to > indicate all interfaces) > - If ''vnc-listen'' is set in /etc/xen/xend-config.sxp, use that > (again can set it to 0.0.0.0 to listen on all interfaces by > default) > - Else use 127.0.0.1 > > So, this makes VNC local only by default using 127.0.0.1. Anyone who wants > the old behaviour can just change xend-config.sxp setting... > > (vnc-listen ''0.0.0.0'') > > ...which will affect all guests without an explicit setting. > > Signed-off-by: Daniel P. Berrange <berrange@redhat.com> > > Regards, > Dan. > > ------------------------------------------------------------------------ > > diff -r 593b5623a0d2 tools/examples/xend-config.sxp > --- a/tools/examples/xend-config.sxp Fri Sep 29 15:40:35 2006 +0100 > +++ b/tools/examples/xend-config.sxp Fri Sep 29 13:01:11 2006 -0400 > @@ -130,3 +130,8 @@ > > # The tool used for initiating virtual TPM migration > #(external-migration-tool '''') > + > +# The interface for VNC servers to listen on. Defaults > +# to 127.0.0.1 To restore old ''listen everywhere'' behaviour > +# set this to 0.0.0.0 > +#(vnc-listen ''127.0.0.1'') > diff -r 593b5623a0d2 tools/examples/xmexample.hvm > --- a/tools/examples/xmexample.hvm Fri Sep 29 15:40:35 2006 +0100 > +++ b/tools/examples/xmexample.hvm Fri Sep 29 13:01:11 2006 -0400 > @@ -132,6 +132,11 @@ vnc=1 > vnc=1 > > #---------------------------------------------------------------------------- > +# address that should be listened on for the VNC server if vnc is set. > +# default is to use ''vnc-listen'' setting from /etc/xen/xend-config.sxp > +#vnclisten="127.0.0.1" > + > +#---------------------------------------------------------------------------- > # set VNC display number, default = domid > #vncdisplay=1 > > diff -r 593b5623a0d2 tools/ioemu/vl.c > --- a/tools/ioemu/vl.c Fri Sep 29 15:40:35 2006 +0100 > +++ b/tools/ioemu/vl.c Fri Sep 29 13:01:11 2006 -0400 > @@ -122,6 +122,7 @@ int nographic; > int nographic; > int vncviewer; > int vncunused; > +struct sockaddr_in vnclisten_addr; > const char* keyboard_layout = NULL; > int64_t ticks_per_sec; > char *boot_device = NULL; > @@ -2783,10 +2784,24 @@ fail: > return -1; > } > > +int parse_host(struct sockaddr_in *saddr, const char *buf) > +{ > + struct hostent *he; > + > + if (isdigit(buf[0])) { > + if (!inet_aton(buf, &saddr->sin_addr)) > + return -1; >Valid hostnames can begin with a digit as long as there are non-digits in the name. What I normally do is try inet_aton() iff gethostbyname fails first. Regards, Anthony Liguori> ------------------------------------------------------------------------ > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Sep 29, 2006 at 01:03:02PM -0500, Anthony Liguori wrote:> > > >+int parse_host(struct sockaddr_in *saddr, const char *buf) > >+{ > >+ struct hostent *he; > >+ > >+ if (isdigit(buf[0])) { > >+ if (!inet_aton(buf, &saddr->sin_addr)) > >+ return -1; > > > > Valid hostnames can begin with a digit as long as there are non-digits > in the name. What I normally do is try inet_aton() iff gethostbyname > fails first.Yeah, should have thought about possibility of using a hostname instead of IP address. Will update the patch to try what you suggest here. We''ve also got an equivalent patch for the para-virt framebuffer which I''ll post later too. 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@lists.xensource.com http://lists.xensource.com/xen-devel
Attached is a 3rd iteration of the patch which changes address lookup so
that gethostbyname is tried first, then falling back to inet_ntoa. Tested
it working with a variety of hostnames, some starting with digits, and
tested with 0.0.0.0, 127.0.0.1 and a non-localhost IP.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Regards,
Dan.
On Fri, Sep 29, 2006 at 01:03:02PM -0500, Anthony Liguori
wrote:>
> >Ok, attached is an adaptation of Jeremy''s initial patch to do
this.
> >
> >The logic for determining which interface to listen on goes like this:
> >
> > - If ''vnclisten'' is set in guest config, use that
(can use 0.0.0.0 to
> > indicate all interfaces)
> > - If ''vnc-listen'' is set in
/etc/xen/xend-config.sxp, use that
> > (again can set it to 0.0.0.0 to listen on all interfaces by
> > default)
> > - Else use 127.0.0.1
> >
> >So, this makes VNC local only by default using 127.0.0.1. Anyone who
wants
> >the old behaviour can just change xend-config.sxp setting...
> >
> > (vnc-listen ''0.0.0.0'')
> >
> >...which will affect all guests without an explicit setting.
> >
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> >
> >Regards,
> >Dan.
> >
>
>------------------------------------------------------------------------
> >
> >diff -r 593b5623a0d2 tools/examples/xend-config.sxp
> >--- a/tools/examples/xend-config.sxp Fri Sep 29 15:40:35 2006 +0100
> >+++ b/tools/examples/xend-config.sxp Fri Sep 29 13:01:11 2006 -0400
> >@@ -130,3 +130,8 @@
> >
> > # The tool used for initiating virtual TPM migration
> > #(external-migration-tool '''')
> >+
> >+# The interface for VNC servers to listen on. Defaults
> >+# to 127.0.0.1 To restore old ''listen everywhere''
behaviour
> >+# set this to 0.0.0.0
> >+#(vnc-listen ''127.0.0.1'')
> >diff -r 593b5623a0d2 tools/examples/xmexample.hvm
> >--- a/tools/examples/xmexample.hvm Fri Sep 29 15:40:35 2006 +0100
> >+++ b/tools/examples/xmexample.hvm Fri Sep 29 13:01:11 2006 -0400
> >@@ -132,6 +132,11 @@ vnc=1
> > vnc=1
> >
> >
#----------------------------------------------------------------------------
> >+# address that should be listened on for the VNC server if vnc is set.
> >+# default is to use ''vnc-listen'' setting from
/etc/xen/xend-config.sxp
> >+#vnclisten="127.0.0.1"
> >+
>
>+#----------------------------------------------------------------------------
> > # set VNC display number, default = domid
> > #vncdisplay=1
> >
> >diff -r 593b5623a0d2 tools/ioemu/vl.c
> >--- a/tools/ioemu/vl.c Fri Sep 29 15:40:35 2006 +0100
> >+++ b/tools/ioemu/vl.c Fri Sep 29 13:01:11 2006 -0400
> >@@ -122,6 +122,7 @@ int nographic;
> > int nographic;
> > int vncviewer;
> > int vncunused;
> >+struct sockaddr_in vnclisten_addr;
> > const char* keyboard_layout = NULL;
> > int64_t ticks_per_sec;
> > char *boot_device = NULL;
> >@@ -2783,10 +2784,24 @@ fail:
> > return -1;
> > }
> >
> >+int parse_host(struct sockaddr_in *saddr, const char *buf)
> >+{
> >+ struct hostent *he;
> >+
> >+ if (isdigit(buf[0])) {
> >+ if (!inet_aton(buf, &saddr->sin_addr))
> >+ return -1;
> >
>
> Valid hostnames can begin with a digit as long as there are non-digits
> in the name. What I normally do is try inet_aton() iff gethostbyname
> fails first.
>
> Regards,
>
> Anthony Liguori
>
>
>------------------------------------------------------------------------
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xensource.com
> >http://lists.xensource.com/xen-devel
> >
>
--
|=- 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@lists.xensource.com
http://lists.xensource.com/xen-devel