[kwlug disc.] Understanding the X Window System
Unsolicited
unsolicited at gto.net
Tue Feb 6 16:53:16 EST 2007
It is seldom obvious, but you are crossing a whole bunch of issues
here. It can be irritating how things appear to overlap and
inter-relate, certainly I get confused.
{These are only my opinions and experiences, and others will have more
detailed and more knowledgeable information, in some areas.}
I'm not Chris, but perhaps useful in a generic way.
>>>>>
I had heard that VNC wasn't as secure as ssh, so one should always use
ssh. Seems like any ssh session that exports X isn't so safe..
depending on the machine you're connecting to... etc. I did read the
section on VNC you provided below - the URL. VNC works more like a
traditional client-server, whereas exporting X through ssh (or port
forwarding) the data is exported but the X server is on your local
machine. Do I have this right? And X server uses udp - is that what
you said? In looking up VNC it says it uses something called remote
framebuffer. For some reason I thought VNC used screen scrapes. VNC
doesn't use encryption by default I thought. On KDE it's called Krfb
or KDE remote desktop sharing - there is one Gui to configure both on
SLED. "Desktop Sharing is the KDE server for the Remote Frame Buffer
protocol. Remote Desktop Connection is the KDE client for the Remote
Frame Buffer protocol."
<<<<<
> I had heard that VNC wasn't as secure as ssh
Divide up remote access / viewing and remote access / 'network
inter-connection'
First, deal with remote access / 'network connection'. (1) Everyone
has, or should, have a firewall - if your firewall doesn't let those
ports in, it's a non-issue. Most don't have the ports open, but it
gets more risky when you (typically) open a range or ports, usually
'high' up, for things like Torrent. (2) Not usually an issue for home
users, but the network of computers behind the firewall are at risk
from each other. Typically the I.T. Administrators implement a
consistent authentication behaviour and each remote viewing mechanism
follows it or has their own (such as VNC). One doesn't usually have to
worry about their co-workers, and I.T. Admins. normally require you to
make your machine available (for good reason).
UDP and TCP are equally 'secure' - TCP has more overhead, but is more
deterministic. TCP doesn't typically open a wide range of higher
ports, for things like Torrent. Torrent is fairly unusual, and cool,
for having its own mechanism for making sure each packet was correctly
received, and for reordering them as necessary.
So, if a VNC port isn't open on the firewall, but ssh is, you can
limit the things you need to worry about. And so on.
SSH is a wonderful thing in several ways. Because you can tunnel
through it, you can, for example, leave only one port open on the
firewall, then tunnel VNC through it.
Moreover, at its most secure form, SSH can be used with certificates
(only, or as well). A file, usually generated on the ssh server by the
ssh administrator must be present on the calling computer - if the
server requires it, and you don't have it, goodbye. This avoids the
whole snooping, cracking passwords, and everything else, problem. If
you lose the key (a) you don't get in, (b) a simple deletion operation
on the server renders the certificate useless, should your laptop get
stolen or something. You can give the same certificate to multiple
things - which allows all of them to talk to ssh - usually then there
are additional userids/passwords used to direct the individual to
their specifics. [Access separated from individual authentication /
permission.]
So, things are not exclusive to still requiring a userid or password,
and if you want to use VNC, allowing port forwarding. ssh can be
secure as you want it to be.
SSH is wonderful because of it's universality. Other forms of
encryption, https, gnuPG, etc. tend to be application specific. An
encrypted e-mail or web session, for example. Or mail client / server
communication (and authentication). One ssh and you can do all of
these through it, without the additional complexity for each and every
application you seek security with - and everything you use comes
along for the security ride, not just that one application.
Second, remote viewing. There are more VNC clients out there than you
can shake a stick at. None to my knowledge encrypt the viewing, which
should not matter anyways - you have to have allowed the remote viewer
in, they have to be watching you at the time, and you have to be doing
something worth watching at the time. I believe there are now
utilities to record VNC sessions, but as a snooping tools I don't
believe it to be practical - storage and bandwidth requirements would
consume quite a bit, in the hope something useful will be gleaned.
All, except below, to my knowledge, pass the userid, if there is one,
in open text, and an encrypted password. Every combination of things
is out there. If you assume ssh between networks, then which VNC
client you use shouldn't matter.
One, tight VNC, combines ssh and VNC to give you absolutely secure
access, so no worries about snooping. It is well regarded.
But, you're right, in the end, VNC via ssh is more secure. And having
gone through the pain of setting up ssh, everything else comes along
for the ride.
Your question of bandwidth is exactly why I asked about the load of
remote X vs VNC at the meeting. FreeNX was mentioned to lower this
bandwidth. As I was reminded at the meeting - the use of either goes
back to your remote access requirements and your authentication
methods. VNC is typically used to remote access the same screen as the
user - be it for support, collaboration, or using the work environment
from home. Everything else is typically used for a remote computer to
take advantage of remote services a computer offers. Be it a mail
server, a web server, a company Intranet, an internal application
securely tunnelled through ssh, and so on. VNC has its own
authentication, whereas ssh, even the X/ssh combination, uses the
authentication methods already set up - another verification method
need not be set up.
X&ssh (as a single 'unit') can be used, in a 'sense' it's just a
different form of VNC, but if you're going to have to set up ssh
anyways in order to use it ...
Having said all this ... setting up an ssh server is irritating
enough, I wouldn't want to have to implement it on every computer.
VNC, though, brings so much usefulness that it is worth setting on
every computer (with no user acceptance required) - everyone has to
decide on their own risk acceptance levels, but for an internal
network, in my opinion, setting up ssh on every computer isn't worth
the aggravation.
For an internal network, bandwidth consumption probably isn't going
to matter. For inter-networks, assume ssh is required, and, you'll
always be limited by your inter-network speed. Once it gets beyond the
ssh server, the ssh overhead is gone, and you're back to your internal
network speed - which will be slower than the inter-network speed anyways.
In my own experience, you use ssh, VNC, remote x, whatever, because
of the particular requirements of what you are trying to do. Although
one reasonably usually thinks bandwidth should be important, the
requirements of what you are trying to do usually forces you into a
particular mode where you consume whatever bandwidth you need to
consume to satisfy the requirement. Only then do things like freeNX
become an issue.
As you have noted, it is not atypical for RDP (aka MS Windows Terminal
Server) and VNC have been combining clients, and most every distro has
a VNC client easily available. RDP is another option, just as secure
as https.
So, RDP is yet another option, in the typical plethora of choices
GNU/Linux offers.
It's easy to forget that everything that gets set up also imposes
some level of maintenance - consuming time and involving aggravation.
Implementing ever form of remote connectivity possibly would just be
irritating. Which is only to say - every mechanism involves some level
of work, using ssh once, only, can reduce that.
FWIW, the presence of any of the above does not mean that gnuPG,
etc., aren't still needed or useful. These, in the end, as they are
typically used today, have more to do with end to end / client to
client / individual to individual secure communications, whereas the
above has to do with inter-network communication and access, and
inter-computer access. [vs. person to person access such as via e-mail.]
> I"m assuming if you use ssh only it doesn't produce the
> mit.magic.cookies file. My understanding is that ssh uses the
> public key from the server and the public key from the client to
> encrypt the data stream. If the client's public key is found on the
> server, then
And we're back to
>>>>>
It is seldom obvious, but you are crossing a whole bunch of issues
here. It can be irritating how things appear to overlap and
inter-relate, certainly I get confused.
<<<<<
ssh CAN use userids, passwords, certificates, or one or all.
Certificates are similar beasties to what gnuPG and https use. Usually
all placed in different places. [This is why things like PAM, and
non-VNC authentication mechanisms that use it, can reduce the
complexity in your life.] X's magic cookies are equivalent to SSH's
certificates. Otherwise, one has zero to do with the other.
With two way encryption (?) having one key allows you to decrypt
something encrypted with the other key. Sessions go something like two
magic/random numbers are generated. Each side then agrees to use these
numbers for further (negotiation) communications. Assuming each side
has the other's public key, one encrypts 'I am me' with their private
key, then encrypts with the agreed key. The other decrypts on the
agreed key, then decrypts on the other side's public key, and things
proceed. Ultimately the negotiated stuff times out, and a new
negotiation occurs, but the public/private key stuff still plays a
role. Essentially: I encrypt with my private key so you can decrypt
with my public key. You encrypt with my public key so only I can
decrypt with my private key. [And access to the private key is also
typically password protected.]
That is snooping security (encryption) and authentication (it really
came from you, and only you can read it).
Before you complete the process, you will have had to go through a
permissions validation as well. Just because public keys have been
exchanged, doesn't mean you're allowed to talk. The server still has
to allow you to talk. Authorizing you may or may not involve
certificates, userids, and passwords, or all of the above.
> I'm assuming that if your home directory mounted as a fileshare then
> possibly your hidden directory for .gnupg could be also more or less
Mounting as a file share doesn't necessarily mean you have access.
George may be able to see it can be mounted, but that doesn't
necessarily mean he has the password in order to see the files within
it.
> available. When I looked at the file on my machine it's a binary
> file - so would that make it more protected?
Typically a password is required to decrypt, so even if you get the
file / have access to it, the binary data needs the additional
password to make use of it. (The contents make no sense without it.)
FWIW
Good luck.
Oksana Goertzen wrote, On 2/06/2007 2:48 PM:
> Hi Chris,
>
> I looked around for ddcprobe but I'm not finding it on SuSE. I did find
> documentation on it on the net. I downloaded a copy of the live cd for
> Knoppix - so I'll see if it's included there. I'm running SLED at work
> - so maybe it's not included in favour of SaX2. I can look at my home
> system running openSuSE and see if it's there.
>
> Here's some brief info on SaX2.
> http://sax.berlios.de/
>
> If you want a look at openSuSE - I have the DVD downloaded at work and I
> also have copies of SLED 10 and SLES 10. And, I don't know if you wear
> baseball caps, I do have a couple of Novell/SuSE ones. They always seem
> to give them out on training or when I go to events and I get a
> collection. [Or maybe you're not too enthused about the Novell + M$
> agreement - same as I ]. Anyhow, if you want one - speak up. I
> vacillated about whether to bring them to kwlug. Maybe Novell is now a
> bad word. :) I haven't decided yet myself. I'm sort of, of the mind,
> M$ is playing divide and conquer and for Novell - it's hard to be
> impartial when you're sleeping with the enemy.
>
> I spent some time going over my notes [and the ones you provided] -
> thanks! Hey, it was a great presentation! The place was quiet when you
> were talking. :)
>
> I had heard that VNC wasn't as secure as ssh, so one should always use
> ssh. Seems like any ssh session that exports X isn't so safe..
> depending on the machine you're connecting to... etc. I did read the
> section on VNC you provided below - the url. VNC works more like a
> traditional client-server, whereas exporting X through ssh (or port
> forwarding) the data is exported but the X server is on your local
> machine. Do I have this right? And X server uses udp - is that what
> you said? In looking up VNC it says it uses something called remote
> framebuffer. For some reason I thought VNC used screen scrapes. VNC
> doesn't use encryption by default I thought. On KDE it's called Krfb or
> KDE remote desktop sharing - there is one Gui to configure both on
> SLED. "Desktop Sharing is the KDE server for the Remote Frame Buffer
> protocol. Remote Desktop Connection is the KDE client for the Remote
> Frame Buffer protocol."
>
> http://www.realvnc.com/howitworks.html
>
> I found in xterm or actually I guess Konsole in KDE that the ctrl-right
> click or ctrl-left click didn't work for the font menu - but it's not
> strictly xterm. However, the ctrl+right click brought up other Konsole
> options. Just using the middle button only pasted a selection (not a
> cut buffer) from Firefox.
>
> I"m assuming if you use ssh only it doesn't produce the
> mit.magic.cookies file. My understanding is that ssh uses the public
> key from the server and the public key from the client to encrypt the
> data stream. If the client's public key is found on the server, then
> you don't have to use a password to connect - but I guess you would need
> the client private key to decrypt the stream of data... so there is
> still something on the client side that needs to be there. It sounds as
> though ssh -X creates a temporary key - and uses this key as a symmetric
> cipher - i.e. that it uses the same key for both encryption and
> decryption... and this key is available for that session, to anyone who
> has root [or can become root] on the system.
>
> I'm assuming that if your home directory mounted as a fileshare then
> possibly your hidden directory for .gnupg could be also more or less
> available. When I looked at the file on my machine it's a binary file -
> so would that make it more protected?
>
> Hey, do you want to go for lunch on Friday? I'll make it easy for you
> - I'll buy. We could go to Country Boy - they have all day breakfast
> [for those who get out of bed at noon!] or wherever else you'd prefer.
> Let me know.
>
> Oksana
>
>
>
> On 2/5/07, *Chris Frey* < cdfrey at foursquare.net
> <mailto:cdfrey at foursquare.net>> wrote:
>
> Hi,
>
> As promised, here is the detailed outline used for tonight's
> presentation.
> There were a lot of good comments during the meeting, talking about
> VNC's
> X server, and FreeNX (?)... please feel free to add more tips to
> this thread.
>
> - Chris
>
>
>
>
>
> Almost all the information presented tonight is available to you
> regardless
> of what desktop you use. I'll be using a lot of low level X commands
> that are on most installations by default.
>
> Ssh will also be used near the end, to point out some security
> considerations.
>
>
> - goals of presentation
>
> - The X model
>
> - XF86Config overview
> - screens bigger than display size? scrolling?
> - Virtual 2048 1024 (in Display subsection)
> - xf86cfg (gui) and xf86config (text) config programs
> - handy keystrokes
> - Ctrl-Alt-Backspace
> - Ctrl-Alt- + and -
> - Ctrl-Alt- F1 to F12
>
>
> - Connecting to your X server
> - display name format:
> hostname:displaynumber.screennumber
> hostname - computer it's running on
> display number - which X server that's running on host
> screen number - which monitor
> - specify:
> - DISPLAY env variable
> - -display command line option
>
>
> - the X startup process
> - starting the X server manually
> - X :1
> - useless
> - xterm -display :1
> - need a window manager!
> - try it: fluxbox -display :1
>
>
> - startx
> - user friendly wrapper for xinit
> - startup scripts in /home/user
> - .xinitrc - default script to start up the
> client
> - .xserverrc - default script for X server
> - xinit kills the X server when client exits (last
> connection)
> - specify the display number
> startx -- :1
>
>
> - xdm/gdm/kdm
> - see below
>
>
> - X managers
> - The display manager - manages logins graphically
> - takes the place of init, getty, login
> - via inittab or daemon
> - xdm starts an X server based on
> /etc/X11/xdm/Xservers
> - remote access from the network
> - port 177, UDP, the xdmcp protocol
> - has to be configured specifically for
> security reasons
> - xdm needs to be "willing"
> - gdm needs xdmcp turned on
> - demo gdm
> - turn on xdmcp in gdm config
> - X :1 -query localhost
>
>
> - The window manager
> - fluxbox
> - gnome / kde
>
>
> - The session manager
> - xsm
> - place at the end of your .xinit
> - rather limited
> - gnome
> - automatic session management in the logout
> screen
> - when using gnome applications, can save even
> small details
> - try metacity
>
>
> - X fonts
> - fonts are loaded from the server's local filesystem, or from
> one or more font servers, or both
> - xfontsel
>
> - Cut and paste
> - the selection and the cut buffer
> - selection - application holds the data for anyone
> that asks
> - cut buffer - X server holds the data
> - xcutsel
> -
> http://www.realvnc.com/pipermail/vnc-list/2001-May/022320.html
> <http://www.realvnc.com/pipermail/vnc-list/2001-May/022320.html>
> - experiment:
> - mozilla works with selection
> - xterm works with both cut buffer and selection
> - xcutsel to work with cut buffer even after
> mozilla
> exits
> - the clipboard
> - xclipboard
> - listens for CLIPBOARD assertions and keeps a stack of
> string data... xterm doesn't do this, but
> mozilla
> does when doing a Copy
>
>
> - X toys
> - xsetroot
> - xsetroot -solid black
> - xsetroot -solid red
> - xsetroot -bitmap pumpkin.xbm
> - bsetroot, part of fluxbox, handles jpg's
> - bitmap
> - xeyes
> - xmag
> - xmessage
> - xmessage -center 'Hello world!'
> - xmessage -center -file Xpresentation.txt
> - taking screenshots with xwd | xwud
> - of the root window (shows everything)
> - xwd -root
> - of a given window
> - xwd by itself, allows selection
> - xwdtopnm
> - convert to pnm
> - ppmtopgm back.ppm | pgmtopbm | pbmtoxbm > back.xbm
> - xwd | xwdtopnm | ppmtopgm | pgmtopbm | pbmtoxbm >
> window.xbm
> - xsetroot -bitmap window.xbm
>
>
> - Poking around the X window system
> - xmodmap
> - xmodmap -pk (gets list of keycodes)
>
> - xset
> - keyboard rate:
> - xset r rate 250 30
> - turning autorepeat on/off per key
> - xset -r 65 (spacebar)
>
> - xls* family
> - xlsclients Shows client programs currently
> connected
> - xlsfonts
> - xfd -fn <name>
> - xlsatoms
> - atom: (1.) A unique ID corresponding to a
> string
> name. Atoms are used to identify
> properties,
> types, and selections.
>
> - info family
> - xdpyinfo
> - xwininfo
> - xwininfo -tree -root
> - xwininfo -tree (lets user select window)
> - xfsinfo
> - xfsinfo -server unix/localhost:7100
> - glxinfo (not covered)
> - xvinfo (not covered)
>
>
> - xprop - watching properties
> - mozilla remote
>
> - xev - watching events
>
>
>
> - X authentication
> - X uses "old school" security, like unix itself... there is one
> barrier to getting in, but once you're in, you're IN!
> - xhost
> - allows anyone from one of the listed hostnames access
> - leave this on, with the host list empty
> - xauth
> - MIT magic cookie - used on most linux installs
> - kerberos
> - getting access to X after running "su"
> - xauth, merge, etc
>
>
> - X forwarding
> - ssh -X and ssh -Y
> - forwards a connection via TCP... often port 6010, etc
> - how an attacker might gain access to your X server
> - spying on the visitor (xwininfo)
> - screen captures! (xwd)
> - keyboard sniffing! (xev)
> - mess with his mind!
> - xmessage
> - xwud a picture onto his display
> - xkill
> - not just hacking, but collaboration
> - ooffice -display :0
>
>
>
> - Security recommendations
> - never ssh -X into a machine that:
> - you don't trust (insecure machine, possibly
> hacked, etc)
> - you don't trust all people who have root on that
> machine
> - turn off X forwarding with:
> - ssh -x user at host
> - /etc/ssh/ssh_config (client config)
> - logins can occur via:
> - telnet
> - ssh
> - the X display manager
> - if your home directory is mounted on a network filesystem,
> your
> magic cookies may be travelling the network in the clear
>
> _______________________________________________
> KWLUG-Disc mailing list
> KWLUG-Disc at kwlug.org <mailto:KWLUG-Disc at kwlug.org>
> http://listserv.kwlug.org/mailman/listinfo/kwlug-disc
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> KWLUG-Disc mailing list
> KWLUG-Disc at kwlug.org
> http://listserv.kwlug.org/mailman/listinfo/kwlug-disc
More information about the KWLUG-Disc
mailing list