[Debian]: Re: Warum xhost böse ist (was: Mozilla)?Message-ID: <19990721035018.A6290@rincewind.informatik.uni-hamburg.de>
>> "MW" == M Welle <m.welle@gmx.net> wrote:
MW> wenn ich xdm+chooser benutze, gehen passwd doch auch im Klartext
MW> ueber die Leitung?
Ja.
MW> Gibt es eine FAQ, die zusammenfasst, wie da die Zusammenhaenge
MW> sind bzw. wie der login da funktioniert?
Ist mir direckt so nicht bekannt. Vielleicht mal auf securityfocus.com
umschauen.
Vielleicht auch mal das security guide auf
https://www.seifried.org/lasg/ durchlesen.
Ach ja, zum Thema xhost habe ich noch folgenden Artikel gespeichert:
From: "Christian Hudon" <chudon@ee.mcgill.ca>
Date: Sat, 21 Jun 1997 14:48:19 +0000
To: Gernot Bauer <Gernot.Bauer@jk.uni-linz.ac.at>
Cc: "debian-user@lists.debian.org" <debian-user@lists.debian.org>
Subject: "xauth +", not a good idea...
On Jun 21, Gernot Bauer wrote
> > Hi,
> > I recently upgraded my Xfree setup to 3.3 from unstable. But now I seem
> > to have some problems.
> > Only the user that runs the xserver (startx) can run apps on it
> > any attempt to run an app by another user is refused. eg below;
> >
> ># xhost
> >
> >Xlib: connection to ":0.0" refused by server
> >Xlib: Invalid MIT-MAGIC-COOKIE-1 key
> >xhost: unable to open display ":0.0"
> >#
>
> Isnt this a "feature"? Did you try "xhost +"? My root-user also must not
> open windows on my (user-)screen. "xhost +" disables this.
.... and enables anyone on the Internet to connect to your X server and,
say, stuff the string "rm -rf /" in an open root xterm. Or read everything
you type, inluding passwords.
Doing "xhosts +" in response to an "Invalid MIT-MAGIC-COOKIE-1 key" is
pretty much the equivalent of making all files writable by anyone ("chmod
-R ugo+w /") and setting all the passwords to "" in response to a
"permission denied" error when trying to access a file. Anyone that can get
to your machine can now do pretty much anything they want to it. So, unless
your machine is never connected to any kind of network, it's definitely a
*bad* idea. And the "Invalid MIT-MAGIC-COOKIE-1 key" message that other
users get when trying to connect to your X server is definitely a *feature*
(enclosed in stars) as opposed to a "feature" (enclosed in quotes).
If you trust everyone who has a login on your machine, do "xhost
+local:" instead of "xhost +". This will allow only non-network, local
connections to your X server.
If you don't trust every user on your machine, you'll need to learn a bit
about xauth. "xauth list $DISPLAY" will list the key for the display
$DISPLAY.
foo@pianocktail:[~]> xauth list $DISPLAY
pianocktail.org/unix:0 MIT-MAGIC-COOKIE-1 53a82429fe56a1cf5236f3d4852e7d79e
Anyone who has that key is authorized to connect to the X server managing
display $DISPLAY. So say you want to grant user bar access to the display
that user foo is using, you just do (as bar):
bar@pianocktail:[~]> xauth add pianocktail.org/unix:0 MIT-MAGIC-COOKIE-1
53a82429fe56a1cf5236f3d4852e7d79e
(Everything after the 'add' was copied (using cut and paste) from the
output of the 'xauth list' command.)
You can automate this a bit more if you can use something like rsh or
ssh. Then doing (as user foo):
foo@pianocktail:[~]> xauth extract - $DISPLAY | ssh -l bar localhost merge -
will give user bar the same access rights over the display $DISPLAY as user
foo. By changing 'localhost' to some other host name, you can give a user
logged onto another machine access to your display. (extract/merge work in
a binary format instead of text, so they're not really suitable for cut and
paste work.)
If you logged in as a non-root user and want to give root on that machine
the right to open xterms, etc. (maybe you want to install the latest Debian
packages from stable), there's an even easier way. Since root can read
other users' files, you can just tell root to use user foo's $HOME/.Xauthority
file (which is where all the information we've just manipulated using
'xauth' is stored)... Just setting root's XAUTHORITY environment variable to
(say) /home/foo/.Xauthority will tell root to use the keys contained in
that file when she needs to authenticate herself to the X server (to, say,
open an xterm).
I hope I've been convincing enough on these two points:
1. Doing "xhost +" is simply a *bad* idea.
2. Doing it right (i.e. with xauth, .Xauthority and MIT magic cookies)
really isn't that hard.
If you have questions, please don't hesitate to ask here
Christian
Debian Security Officer
PS Not that the MIT magic cookie scheme is perfect... The cookies aren't
encrypted when they are transfered between the X client and the X
server. So if you're connecting over a network, people who can snoop on
your packets can grab the magic cookie and then use it to connect to your X
server and do nasty stuff. But that's quite a bit harder to do. And since
it requires snooping, it won't work for local X connections. If you want to
do remote X connections securely, you really want to have a look at ssh. It
makes it easier to have secure X connections than unsecure ones. (No need
to do any "xauth" stuff.) There's a Debian package for it on the Debian
non-US ftp site.
PPS Where do people learn to "xauth +"? Would having a file that explains
what the Right Thing (tm) to do is be a good idea? Something that would get
installed with Debian's X11 packages, or something...
------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <deine emailadresse>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder: 737
Reply to: