Re: security, cvs, was Re: interface bindings of x-server

Re: security, cvs, was Re: interface bindings of x-server

[devzero]

Hi!

i`d like if discussion "unix domain socket vs.  127.0.0.1/TCP for local X connections" would be a complete separate discussion thread. could we separate this?

ok, it seems my thread has alreade become somewhat a separate one (the "was" in the subject line)   ;)

MY intention with this thread is , just to add feature to X-Server which enables binding to dedicated interfaces - which is a quite common feature for popular server-daemons. being able to tune the interface bindings of an applications is a matter of "good implementation style", IMHO.
I wished if i could do that with ALL applications which bind to interfaces.
I`m sure this feature is easy to implement (because there are tons of code examples on the net and because it seems to be already in tightvnc).

is there anybody who already thinksa about doing that ?
i`m really a bad programmer - maybe i could try my luck with that - but i don`t like it starting such work and fiddling around for some days and then somebody says: ok - i`ve done it. was just 5 mins - TRIVIAL ! :D

regards
roland


Keith Packard <keithp@keithp.com> schrieb am 19.11.03 10:35:24:
> 
> 
> Around 10 o'clock on Nov 19, "roland@webde" wrote:
> 
> > the only chance to get rid of it, is to use unix domain socket (via
> > -nolisten tcp)
> 
> That option should be the default; ssh refuses to listen on a unix 
> domain socket, but appears quite happy to connect to a unix domain 
> socket.
> 
> I don't know of any compelling reason to run X raw over TCP/IP these days; 
> it's insecure, and a bandwidth pig.
> 
> -keith
> 
> 


______________________________________________________________________________
WEB.DE FreeMail wird 5 Jahre jung! Feiern Sie mit uns und
nutzen Sie die neuen Funktionen http://f.web.de/features/?mc=021130

Re: interface bindings of x-server

[Keith Packard]

Around 2 o'clock on Nov 19, "roland@webde" wrote:

> Keith, could you put this (being able to specify the interface bindings of
> the xserver on the commandline) as a feature request on http://
> www.freedesktop.org/Software/XserverWishlist if you find this feature
> request useful ? i registerd a wiki account, but logging in doesn`t seem to
> work for me.

I'd like to switch the server so that -nolisten tcp is the default; I 
don't see much sense in having it listen to even 127.0.0.1.  But, if you 
wanted to make the list of IP addresses that the server bound to 
configurable, that seems like a good idea.

ssh -X -C should be the only way to talk to an X server over the network, 
at least for now.  If we find a better way in the future, we might revisit 
this.

Patches to implement any such changes would be gratefully accepted to the 
fd.o X server tree.

The wiki has anti-defacement "security"; please ask most anyone on
#freedesktop to be added to the list of accounts with wiki write access.

-keith

security, cvs, was Re: interface bindings of x-server

[Keith Whitwell]

Keith Packard wrote:
> Around 2 o'clock on Nov 19, "roland@webde" wrote:
> 
> 
>>Keith, could you put this (being able to specify the interface bindings of
>>the xserver on the commandline) as a feature request on http://
>>www.freedesktop.org/Software/XserverWishlist if you find this feature
>>request useful ? i registerd a wiki account, but logging in doesn`t seem to
>>work for me.
> 
> 
> I'd like to switch the server so that -nolisten tcp is the default; I 
> don't see much sense in having it listen to even 127.0.0.1.  But, if you 
> wanted to make the list of IP addresses that the server bound to 
> configurable, that seems like a good idea.

Yep - network transparency is all well & good, but do you really want 
something as complex as the X server sitting there with an open port to the world?

On a related issue, does anyone understand what the actual flaw in pserver CVS 
is that allowed the linux backdoor attempt?  There's been a lot of talk about 
the implications of the attempt, but I haven't heard anyone come out and say 
"This is the fault in CVS, here's a patch, everything's ok now".

Is it foolhardy to continue running anoncvs, especially without the checks & 
balances which caught the backdoor attempt in linux?

Keith

Re: security, cvs, was Re: interface bindings of x-server

[Keith Packard]

Around 8 o'clock on Nov 19, Keith Whitwell wrote:

> Is it foolhardy to continue running anoncvs, especially without the checks & 
> balances which caught the backdoor attempt in linux?

The pserver running on fd.o has been specially hacked to run as 'nobody' 
from the very start, unlike most pserver implementations which run as root 
and setuid to the user specified in the CVS password file.  I think this 
should make it rather difficult to affect any of the repositories on fd.o 
unless files in those directories are world writable.

But, if we want to be extra paranoid, the right solution is to have 
anoncvs use a separate mirror machine rsynced from the main repository.  
I'd like to avoid that as it makes anoncvs 'second class' which seems like 
it will encourage more people to ask for project membership that they 
otherwise don't really need just to avoid the anoncvs delay.

Of course, an even better solution would be to throw CVS in the garbage 
and use some more robust configuration management system.  Sigh.

-keith

Re: security, cvs, was Re: interface bindings of x-server

[roland@webde]

hi

> Yep - network transparency is all well & good, but do you really want
> something as complex as the X server sitting there with an open port to the world?
exactly _THIS_ _IS_ what causese my headache! there _IS_ something as complex as the X server
sitting there with an open port to the world - per default!
the only chance to get rid of it, is to use unix domain socket (via -nolisten tcp)  OR to
add the option, to specify the interface bindings and be able to bind it to local loopback
ONLY. I`d prefer the second one.
BTW: on a server "out there on the internet" i even run samba - and i`m shure it never get`s
hacked cause of a samba exploit. why? because i bound it to 127.0.0.1 only - and i`m doing
ssh portforwarding with that.

ahhhh - btw - i see:
on http://www.tightvnc.com/changelog-unix.html
2001-01-17 01:55 const
Xvnc/programs/Xserver/hw/vnc/: init.c, rfb.h, sockets.c: Support for Xvnc -interface
option added (patch from Tim Waught).

feature seems to be in tightvnc already - so maybe we need just some code transfer (since vnc is xfree86
based) ? ;)

regards
roland



----- Original Message ----- 
From: "Keith Whitwell" <keith@tungstengraphics.com>
To: "Keith Packard" <keithp@keithp.com>
Cc: "roland@webde" <devzero@web.de>; <cygwin-xfree@cygwin.com>; <xserver@pdx.freedesktop.org>; "dri-devel"
<dri-devel@lists.sourceforge.net>
Sent: Wednesday, November 19, 2003 9:15 AM
Subject: security, cvs, was Re: interface bindings of x-server


> Keith Packard wrote:
> > Around 2 o'clock on Nov 19, "roland@webde" wrote:
> >
> >
> >>Keith, could you put this (being able to specify the interface bindings of
> >>the xserver on the commandline) as a feature request on http://
> >>www.freedesktop.org/Software/XserverWishlist if you find this feature
> >>request useful ? i registerd a wiki account, but logging in doesn`t seem to
> >>work for me.
> >
> >
> > I'd like to switch the server so that -nolisten tcp is the default; I
> > don't see much sense in having it listen to even 127.0.0.1.  But, if you
> > wanted to make the list of IP addresses that the server bound to
> > configurable, that seems like a good idea.
>
> Yep - network transparency is all well & good, but do you really want
> something as complex as the X server sitting there with an open port to the world?
>
> On a related issue, does anyone understand what the actual flaw in pserver CVS
> is that allowed the linux backdoor attempt?  There's been a lot of talk about
> the implications of the attempt, but I haven't heard anyone come out and say
> "This is the fault in CVS, here's a patch, everything's ok now".
>
> Is it foolhardy to continue running anoncvs, especially without the checks &
> balances which caught the backdoor attempt in linux?
>
> Keith
>

Re: security, cvs, was Re: interface bindings of x-server

[Keith Packard]

Around 10 o'clock on Nov 19, "roland@webde" wrote:

> the only chance to get rid of it, is to use unix domain socket (via
> -nolisten tcp)

That option should be the default; ssh refuses to listen on a unix 
domain socket, but appears quite happy to connect to a unix domain 
socket.

I don't know of any compelling reason to run X raw over TCP/IP these days; 
it's insecure, and a bandwidth pig.

-keith

Re: security, cvs, was Re: interface bindings of x-server

[Corinna Vinschen]

On Wed, Nov 19, 2003 at 01:35:20AM -0800, Keith Packard wrote:
> 
> Around 10 o'clock on Nov 19, "roland@webde" wrote:
> 
> > the only chance to get rid of it, is to use unix domain socket (via
> > -nolisten tcp)
> 
> That option should be the default; ssh refuses to listen on a unix 
> domain socket, but appears quite happy to connect to a unix domain 
> socket.
> 
> I don't know of any compelling reason to run X raw over TCP/IP these days; 
> it's insecure, and a bandwidth pig.

AF_LOCAL sockets are implemented using AF_INET sockets on Cygwin, using
a binding of 127.0.0.1 plus some overhead for security reasons.  So
AF_LOCAL sockets are a few percent slower than AF_INET sockets.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

Re: security, cvs, was Re: interface bindings of x-server

[Alan Coopersmith]

roland@webde wrote:
> the only chance to get rid of it, is to use unix domain socket (via -nolisten tcp)  OR to
> add the option, to specify the interface bindings and be able to bind it to local loopback
> ONLY. I`d prefer the second one.

Why?  What benefit does a TCP loopback connection provide over the Unix
domain socket (which is generally faster on most OS'es)?

> ahhhh - btw - i see:
> on http://www.tightvnc.com/changelog-unix.html
> 2001-01-17 01:55 const
> Xvnc/programs/Xserver/hw/vnc/: init.c, rfb.h, sockets.c: Support for Xvnc -interface
> option added (patch from Tim Waught).
> 
> feature seems to be in tightvnc already - so maybe we need just some code transfer (since vnc is xfree86
> based) ? ;)

Only if the original author of the tightvnc changes agrees to
distribute under the X license instead of tightvnc's GPL.

-- 
	-Alan Coopersmith-         alan.coopersmith@sun.com
	 Sun Microsystems, Inc.    -     Sun Software Group
	 User Experience Engineering: G11N: X Window System

Re: security, cvs, was Re: interface bindings of x-server

[roland@webde]

hi !

> > the only chance to get rid of it, is to use unix domain socket (via -nolisten tcp)  OR to
> > add the option, to specify the interface bindings and be able to bind it to local loopback
> > ONLY. I`d prefer the second one.
> 
> Why?  What benefit does a TCP loopback connection provide over the Unix
> domain socket (which is generally faster on most OS'es)?
the benefit would be compatibility, IMHO.
think of a scenario where cygwin/xfree86 + native win32 ssh client are combined. i`m sure, this isn`t too 
exotic - e.g. i know a _LOT_ of people who do ssh-tunneling via native win32 ssh client "putty" in combination 
with a local separate xserver on their windoze box. does anybody know if any "native" or "non cygwin based" ssh client 
on windows is able to use cygwin/xfree86 unix domain socket on win32 machine? i`m not sure - but i don`t think so.

but, anyway - being able to bind to 127.0.0.1 would be just ONE "special case" of a more general "dedicated interface 
binding feature". nobody says , that you _should_ use 127.0.0.1 - but you always would have an option, to do so.
i`m sysadmin - i like options. ;)

> > feature seems to be in tightvnc already - so maybe we need just some code transfer (since vnc is xfree86
> > based) ? ;)
> 
> Only if the original author of the tightvnc changes agrees to
> distribute under the X license instead of tightvnc's GPL.
oh - pardon! sure! thanks for bringing that back to my mind that this needs to be adressed!
i`m currently digging into tightvnc to get sure it IS the appropriate code at all.

regards
roland

Re: security, cvs, was Re: interface bindings of x-server

[Dave Dodge]

On Wed, 19 Nov 2003, Alan Coopersmith wrote:
> roland@webde wrote:
> > the only chance to get rid of it, is to use unix domain socket
> > (via -nolisten tcp) OR to add the option, to specify the interface
> > bindings and be able to bind it to local loopback ONLY. I`d prefer
> > the second one.
>
> Why?  What benefit does a TCP loopback connection provide over the Unix
> domain socket (which is generally faster on most OS'es)?

Just a data point: I have lots of special-purpose accounts on my
desktop system, for example when building package XYZ I might create a
specific "xyz" user and group to do the build work, own the resulting
files, etc. So it's very common for me to su over to one of these
accounts and run things like emacs or application-specific GUI tools
as that special user. I use "xhost +localhost" to let these other
accounts display on my desktop; but I basically never have the need
for connections to port 6000 from off-machine anymore (I use ssh for
that instead).

[I realize xauth, or changing permissions on the unix socket, could
probably solve this as well. But the localhost method is really,
really easy :-]

                                                  -Dave Dodge

Re: security, cvs, was Re: interface bindings of x-server

[Alan Coopersmith]

Dave Dodge wrote:
>>Why?  What benefit does a TCP loopback connection provide over the Unix
>>domain socket (which is generally faster on most OS'es)?
> 
> 
> Just a data point: I have lots of special-purpose accounts on my
> desktop system, for example when building package XYZ I might create a
> specific "xyz" user and group to do the build work, own the resulting
> files, etc. So it's very common for me to su over to one of these
> accounts and run things like emacs or application-specific GUI tools
> as that special user. I use "xhost +localhost" to let these other
> accounts display on my desktop; but I basically never have the need
> for connections to port 6000 from off-machine anymore (I use ssh for
> that instead).
> 
> [I realize xauth, or changing permissions on the unix socket, could
> probably solve this as well. But the localhost method is really,
> really easy :-]

"xhost +LOCAL:" would be the equivalent for the Unix socket or other
local communications mechanisms.

-- 
	-Alan Coopersmith-         alan.coopersmith@sun.com
	 Sun Microsystems, Inc.    -     Sun Software Group
	 User Experience Engineering: G11N: X Window System

Re: security, cvs, was Re: interface bindings of x-server

[Keith Packard]

Around 18 o'clock on Nov 19, Dave Dodge wrote:

> [I realize xauth, or changing permissions on the unix socket, could
> probably solve this as well. But the localhost method is really,
> really easy :-]

When you say 'xhost +localhost' you're also granting permission for 
applications to connect throught the unix domain socket.  On a system with 
Unix domain sockets, it's hard to see a valid use for 127.0.0.1:6000.

This is in no way meant to disuade people from adding suitable options to 
configure which interfaces the (deprecated) IP listening sockets should 
bind to; I think that's a very useful idea.  I'm just trying to show that 
the need for any IP connections is even less than people imagine.

-keith

Re: security, cvs, was Re: interface bindings of x-server

[Dave Dodge]

On Wed, 19 Nov 2003, Keith Packard wrote:
> Around 18 o'clock on Nov 19, Dave Dodge wrote:
> > [I realize xauth, or changing permissions on the unix socket, could
> > probably solve this as well. But the localhost method is really,
> > really easy :-]
>
> When you say 'xhost +localhost' you're also granting permission for
> applications to connect throught the unix domain socket.

Yeah, about five minutes after I sent that message I started thinking
that I used to use xhost +localhost and then unix:0 to connect from
other accounts, so the xhost must have affected the unix socket
somehow as well. At some point in the past I switched from using
unix:0 to localhost:0 for those cases, but I can't remember if there
was a specific reason for doing so (probably user error).

                                                  -Dave Dodge