IMPORTANT NOTE about the plplot Tcl/TK driver : IF YOU DO NOT HAVE XAUTH STYLE SECURITY ENABLED, YOU ARE VULNERABLE TO OUTSIDE INTRUSION. I MAKE NO CLAIMS THAT PLPLOT/TK IS SAFE AGAINST SUCH AN ATTACK, AND ASSUME NO RESPONSIBILITY FOR RISK. To reiterate the statement made elsewhere: There is no warranty or other guarantee of fitness of this software. It is provided solely "as is". The author(s) disclaim(s) all responsibility and liability with respect to this software's usage or its effect upon hardware or computer systems. OK, now for some clarification. The Tcl7.0/TK3.3 release attempts to improve security by using the Xauthority mechanism (there are other ways but this was a quick fix). To use it, you must either deal with the new access control method or compile Tcl/TK with security off. It's not really a big deal using the new access method but can be anything from only mildly confusing initially to a major pain in the neck. This file contains various comments, tricks, tips, explanations, or anything else I could dig up on Xauthority. xauth-style security really does represent a big improvement over xhost-based access, since xhost leaves you open to intrusion from anyone on the machine you are granting access to. With conventional X applications, the danger is not so great (IMO), for it would take a fairly sophisticated trojan horse to exploit the security leak (a fake xterm, for example). But Tcl/TK changes the nature of this game completely. The incredible power offered by Tcl/TK means much potential for evil as well as good. I will tell you how badly you can be hacked, since the hackers presumably already know this. Say you grant xhost access to a machine where someone wishes to do you harm. This person starts up a "wish" (TK windowing shell) connected to your machine, but modified to not display an actual window so as to not raise your suspicions. A "show interps" command (or something like that) displays the names of the Tcl interpreters that your Tcl/TK applications are using. Then the hacker merely needs to send commands to these interpreters to do nasty things, the classic being "exec rm -rf *". Yes, this is a legal Tcl command. Using xauth this is prevented. You can also prevent it by renaming the dangerous commands in your interpreter to {} (null), thus preventing their use altogether. In fact I do this in plserver.tcl, but prior to plplot 4.99e I had neglected to do it in the TK driver's interpreter as well, meaning I still wasn't safe. This was an oversight on my part, but a very easy one to make, meaning you'd best exercise some caution. If you do NOT have the Tcl/TK xauth security feature enabled (it is possible to compile Tcl/TK with it turned off), and also grant xhost access, you'd best know whether or not your TK apps are hack-resistant. My renaming the "exec" and "open" commands (the latter can be done only after all autoloading takes place) takes care of the two most flagrant examples of security holes, but there may be others, so caveat emptor. Before too long I will also support the Tcl-DP method (sockets) for communication between the client and the renderer. Fortunately, the issue of security was recently taken up in earnest by the Tcl-DP author as well, so I don't see any reasons not to pursue this right away (except lack of time). This will allow better operation of the tk driver across slow networks, as well as actually running the renderer on a different machine as the client. So here is my quickie explanation of how to get Xauthority working. I had no trouble on our HP X terminals, but lots on the console. Your mileage may vary. If you have extreme problems, yell at your vendor, but if you only grant xhost access to secure machines then you might also consider compiling Tcl/TK without the security feature. --------------------------------------------------------------------- First, you need to have a file ~/.Xauthority. If you already have this, you are off to a good start. In this case your X server is already set to use xauth style security. If not, you need to create a ~/.Xauthority file. You can do this by running "xauth" and then making entries. You will need to reset the X server for this change to take effect. If you are at the console this may mean a reboot (my HP running VUE gave me a bit of a hard time). You next disable all xhost based access. This means not only typing "xhost -", but deleting all hosts named as having access when you type "xhost". Finally you ftp your ~/.Xauthority file to your home directory on the machine you are running client X applications. When they start up, they will try to create windows on your local server as specified by DISPLAY (or whatever). The client and server then exchange magic cookies, and when they match, the client gains access and is allowed to make X requests. Note that you may in general need to ftp your ~/.Xauthority file to the desired hosts each session, because at least on my machine the X server writes a new magic cookie in ~/.Xauthority each time it is run. This is basically analogous to reenabling xhost access each time you log in. ----------------------------------------------------------------------- Below I've appended another person's explanation of what needs to be done, as posted on comp.lang.tcl. ----------------------------------------------------------------------- Author: Vivek Khera -*- text -*- Subject: making your X server more secure Originally Written: Tue, 10 Jul 90 12:26:15 -0400 Time-stamp: "August 10, 1993 12:28:31" Here's how I have made my X sessions more secure than just the xhost way. It is mostly transparent, and doesn't allow arbitrary users to plaster windows on my screen, or to snoop at my keyboard. Even people who log into the machine I'm working on can't connect to the server. This whole scheme is based on the MIT-MAGIC-COOKIE scheme, where each client must present to the server a magic cookie to prove that it is allowed to connect. The cookie is kept in a file in your home directory (.Xauthority) which only you are allowed to read. The server reads this file when it starts up, so if you change the cookie file, you will have to restart the server to make it read the new information. Normally you don't need to do this. The .Xauthority files can be merged using the xauth program. See the man page for some more details. Here is how to make yourself "secure": 1. Create a .xserverrc file similar to mine in your home directory. The important part is to pass the "-auth $HOME/.Xauthority" option to the X server on the last line. Here is what my .xserverrc file looks like: --cut here-- #!/bin/sh # for Xsun: # -ar1 NNN set keyboard repeat delay to NNN milliseconds # -ar2 NNN set keyboard repeat rate to NNN milliseconds if test -w /dev/cgthree0 -o -w /dev/cgsix0; then server=Xsun else server=XsunMono fi # we *must* do an exec for the server so that signals are handled properly exec $server -ar1 250 -ar2 20 -auth $HOME/.Xauthority --cut here-- 2. Before you start the X server, be sure to create the .Xauthority file. I wrote a shell script to do this, called newcookie. You must create a new .Xauthority file when you switch machines, as the name of the machine the server is on is part of the authority mechanism. This is how it knows which cookie to send to which server it is connecting to. I run newcookie from my .login file when I am logging into the console. If you run newcookie after you start the X server, you are hosed unless you can remember the random number it generated and recreate the .Xauthority file by hand; otherwise you will have to quit and restart the server. Here is my newcookie program. If you have a program that generates md5 signatures, you can use it to generate a strong random number by passing the -md5 flag. If you have md4, just edit the script to use it instead of md5. If you don't have md4 or md5, then it assumes you have perl to generate random numbers. If you don't have perl, then write your own program to generate a long random number with an even number of hexadecimal digits in it, and then run "xauth add" like in my program. Note that md4 and md5 generate values that an even number of digits long already. An implementation of md5 can be found in Internet RFC 1321. --cut here-- #!/bin/sh # create new .Xauthority file PATH=/usr/local/X/bin:/usr/gnu/bin:$PATH # try some security auth=$HOME/.Xauthority #cp /dev/null $auth # generate a nice long random key if [ "$1" = "-md5" ]; then # use a random noise source and get a strong checksum of it. # this is probably a stronger random number than the other method. key=`pstat -pfS | md5` else # quick and dirty. can probably be recreated if time can be guessed. key=`perl -e 'srand; printf int(rand(100000000000000000))'` # use $key$key to make sure even length. key=$key$key fi # add to auth file. xauth add ${HOST}/unix:0 . $key xauth add ${HOST}:0 . $key --cut here-- 3. Make sure any program you run does not do an xhost + command. This will destroy any security you might gain by using xauth. Notably, the rcmd script does this. 4. Start the X server using startx. Things should be secure now. All new X clients (from R4 and later) understand this authorization scheme, so you should never need to run xhost again. (Unless you are using the standard Ultrix libraries -- but then you get what you deserve.) In fact, xhost should report *no* hosts as being allowed in. ----------------------------------------------------------------------- Here's the (not very helpful) information I got from the man pages: ----------------------------------------------------------------------- From X(1): ACCESS CONTROL An X server can use several types of access control. Mechanisms provided in Release 5 are: Host Access Simple host-based access control. MIT-MAGIC-COOKIE-1 Shared plain-text "cookies". XDM-AUTHORIZATION-1 Secure DES based private-keys. SUN-DES-1 Based on Sun's secure rpc system. vuelogin/Xdm initializes access control for the server, and also places authorization information in a file accessible to the user. Normally, the list of hosts from which connections are always accepted should be empty, so that only clients with are explicitly authorized can connect to the display. When you add entries to the host list (with xhost), the server no longer performs any authorization on connections from those machines. Be careful with this. The file from which Xlib extracts authorization data can be specified with the environment variable XAUTHORITY, and defaults to the file .Xauthority in the home directory. vuelogin/Xdm uses $HOME/.Xauthority and will create it or merge in authorization records if it already exists when a user logs in. If you use several machines, and share a common home directory across all of the machines by means of a network file system, then you never really have to worry about authorization files, the system should work correctly by default. Otherwise, as the authorization files are machine-independent, you can simply copy the files to share them. To manage authorization files, use xauth. This program allows you to extract records and insert them into other files. Using this, you can send authorization to remote machines when you login, if the remote machine does not share a common home directory with your local machine. Note that authorization information transmitted ``in the clear'' through a network file system or using ftp or rcp can be ``stolen'' by a network eavesdropper, and as such may enable unauthorized access. In many environments this level of security is not a concern, but if it is, you need to know the exact semantics of the particular authorization data to know if this is actually a problem. From Xserver(1): SECURITY The sample server implements a simplistic authorization protocol, MIT-MAGIC-COOKIE-1 which uses data private to authorized clients and the server. This is a rather trivial scheme; if the client passes authorization data which is the same as the server has, it is allowed access. This scheme is inferior to host-based access control mechanisms in environments with unsecure networks as it allows any host to connect, given that it has discovered the private key. But in many environments, this level of security is better than the host- based scheme as it allows access control per-user instead of per-host. In addition, the server provides support for a DES-based authorization scheme, XDM-AUTHORIZATION-1, which is more secure (given a secure key distribution mechanism), but as DES is not generally distributable, the implementation is missing routines to encrypt and decrypt the authorization data. This authorization scheme can be used in conjunction with XDMCP's authentication scheme, XDM-AUTHENTICATION-1 or in isolation. The authorization data is passed to the server in a private file named with the -auth command line option. Each time the server is about to accept the first connection after a reset (or when the server is starting), it reads this file. If this file contains any authorization records, the local host is not automatically allowed access to the server, and only clients which send one of the authorization records contained in the file in the connection setup information will be allowed access. See the Xau manual page for a description of the binary format of this file. Maintenance of this file, and distribution of its contents to remote sites for use there is left as an exercise for the reader. The sample server also uses a host-based access control list for deciding whether or not to accept connections from clients on a particular machine. This list initially consists of the host on which the server is running as well as any machines listed in the file /etc/Xn.hosts, where n is the display number of the server. Each line of the file should contain an Internet hostname (e.g. expo.lcs.mit.edu.) There should be no leading or trailing spaces on any lines. For example: joesworkstation corporate.company.com Users can add or remove hosts from this list and enable or disable access control using the xhost command from the same machine as the server. For example: % xhost +janesworkstation janesworkstation being added to access control list % xhost + all hosts being allowed (access control disabled) % xhost - all hosts being restricted (access control enabled) % xhost access control enabled (only the following hosts are allowed) joesworkstation janesworkstation corporate.company.com ----------------------------------------------------------------------- Here's the responses from readers of comp.lang.tcl to my frenzied cry for help: ----------------------------------------------------------------------- From ashoks@duckjibe.Eng.Sun.COM Mon Sep 13 15:53:33 1993 From: ashoks@duckjibe.Eng.Sun.COM (Ashok Singhal) Newsgroups: comp.lang.tcl Subject: Re: New security "feature" in Tk 3.3 Date: 11 Sep 1993 01:23:36 GMT Organization: Sun Microsystems, Inc. Distribution: world Reply-To: ashoks@duckjibe.Eng.Sun.COM NNTP-Posting-Host: duckjibe I managed to get "send" tk3.3b2 to work with a non-local X server after some initial difficulties with xauth (now there's a poorly documented utility; took me several readings of the man page to figure out how to use it, what hex keys were, no cross references, ...) My set up: application is running on a Sparcserver 1000 running Solaris 2.3, X server (i.e. display) is a SS10 running OpenWindows 3 I had xhost- based authorization set up initially, I disabled it and used xauth. Didn't work. I shut down and restarted the window system on the server and set up xauth again and it worked. I have no idea why/how it did not work the first time and worked after I restarted the window system. - Ashok Singhal Sun Microsystems From schwartz@roke.cse.psu.edu Mon Sep 13 15:53:35 1993 Newsgroups: comp.lang.tcl From: schwartz@roke.cse.psu.edu (Scott Schwartz) Subject: Re: New security "feature" in Tk 3.3 In-Reply-To: ashoks@duckjibe.Eng.Sun.COM's message of 11 Sep 1993 01:23:36 GMT Nntp-Posting-Host: roke.cse.psu.edu Date: Sat, 11 Sep 1993 02:12:10 GMT ashoks@duckjibe.Eng.Sun.COM (Ashok Singhal) writes: I have no idea why/how it did not work the first time and worked after I restarted the window system. The X server needs to be started with the ``-auth authfile'' flag. If you create that file and then restart, the openwin script will notice it and invoke the X server with the right parameters. (Under MIT X, See the Xserver and Xsecurity manpages.) From mjl@dino.ph.utexas.edu Tue Sep 14 11:51:35 1993 From: mjl@dino.ph.utexas.edu (Maurice J. LeBrun) Newsgroups: comp.lang.tcl Subject: Re: New security "feature" in Tk 3.3 Date: 14 Sep 93 11:35:21 Organization: The University of Texas at Austin NNTP-Posting-Host: dino.ph.utexas.edu In-reply-to: schwartz@roke.cse.psu.edu's message of Sat, 11 Sep 1993 02:12:10 GMT Status: RO Thanks to all who replied. I have xauth-style access control working perfectly on my HP 720 running HPUX 9.01 and VUE 3.0 now. For most people, the steps: - create the ~/.Xauthority file or make sure it exists - ftp ~/.Xauthority to the remote host - disable xhost access worked fine, so (still having no luck on the system console) I tested it on a nearby X-terminal, and it worked just fine. schwartz@roke.cse.psu.edu (Scott Schwartz) writes: ashoks@duckjibe.Eng.Sun.COM (Ashok Singhal) writes: I have no idea why/how it did not work the first time and worked after I restarted the window system. The X server needs to be started with the ``-auth authfile'' flag. If you create that file and then restart, the openwin script will notice it and invoke the X server with the right parameters. (Under MIT X, See the Xserver and Xsecurity manpages.) This was the key. After poring through the documentation I found I needed to uncomment the line: # Vuelogin*authorize: True in the file /usr/vue/config/Xconfig. But it still wouldn't work, because the X server needed to be restarted. I thought specifying Vuelogin*terminateServer: True would do the job, but it didn't (the X server is normally started by init during bootup). So I rebooted the machine. After that, it worked fine. Quite a lot to go through! Since the release of Tk3.3 will have this security mechanism set by default, it would be a good idea to include a note about getting xauth-style access working on HP's running HPUX/VUE. -- Maurice LeBrun mjl@dino.ph.utexas.edu Institute for Fusion Studies, University of Texas at Austin Faire de la bonne cuisine demande un certain temps. Si on vous fait attendre, c'est pour mieux vous servir, et vous plaire. [menu of restaurant Antoine, New Orleans] From mjl@dino.ph.utexas.edu Fri Sep 17 15:01:21 1993 From: mjl@dino.ph.utexas.edu (Maurice J. LeBrun) Newsgroups: comp.lang.tcl Subject: Re: New security "feature" in Tk 3.3 Date: 17 Sep 93 01:02:08 Organization: The University of Texas at Austin Distribution: comp NNTP-Posting-Host: dino.ph.utexas.edu In-reply-to: ingwa@isy.liu.se's message of 14 Sep 93 08:55:31 GMT Status: RO ingwa@isy.liu.se (Inge Wallin) writes: mjl@dino.ph.utexas.edu (Maurice J. LeBrun) writes: >In a previous article, I wrote: > OK, my first cut at getting up under Tk 3.3b3 result in no major > problems save one: unauthorized attempts to connect. This is due > to the new security check. Turns out if ANY hosts are enabled by > the older xhost mechanism, the Tk send command aborts. [deleted] > Hopefully I am doing something wrong. Any suggestions? Actually, I am very happy that things are as you described. I have written a few programs using tcl/tk, and the send feature was the thing that almost made me have second thoughts. It is such a gigantic security hole that I nearly skipped tk altogether. However, in the end, the ease of use of tcl/tk made me use it anyhow. Well, the point was I couldn't get it to work, period! Kind of useless in that case, eh? Turns out that getting xauth-style security working involves a bit of voodoo sometimes, or so it seems. I agree about the security hole. One of the first things I do in my initial Tcl script is the following: rename exec {} rename open {} I keep it right after any initial autoloads that I expect, but it still is a pain in the butt. What I would like to have is a way to enable a program to receive sends. If this was not used, the program would refuse to execute sends from other applications. One way to do this could be to use "send enable" to enable the send command. Right, me too. It wouldn't be too hard to add such a capability. I read that the favored approach is to have "secure" interpreters; one would communicate by TK send, but not execute -- it would pass what it receives (filtered?) to your internal interpreter. Or something like that, it may be in the workshop proceedings. Due out next release? Inge Wallin ingwa@isy.liu.se Dept. of EE Linkoping University Sweden -- Maurice LeBrun mjl@dino.ph.utexas.edu Institute for Fusion Studies, University of Texas at Austin Faire de la bonne cuisine demande un certain temps. Si on vous fait attendre, c'est pour mieux vous servir, et vous plaire. [menu of restaurant Antoine, New Orleans] From mjl@dino.ph.utexas.edu Wed Sep 15 22:43 CDT 1993 Received: by dino.ph.utexas.edu (1.37.109.4/16.2) id AA05880; Wed, 15 Sep 93 22:41:29 -0500 From: Maurice LeBrun Return-Path: Subject: Re: New security "feature" in Tk 3.3 To: raines@SLAC.Stanford.EDU Date: Wed, 15 Sep 93 22:41:29 CDT Full-Name: Maurice LeBrun Cc: mjl@dino.ph.utexas.edu In-Reply-To: <9309160052.AA20499@unixhub.SLAC.Stanford.EDU>; from "Paul E. Raines" at Sep 15, 93 5:52 pm Mailer: Elm [revision: 70.85] Status: RO > > I hope you can help me. > > I can't get Xauthority to work and the man pages explain > nothing. I am not trying to do anything with Tk yet, just get > it to work in general. I sympathize. I was there, and it is VERY frustrating. > I did > xauth add $DISPLAY . 12345678901234567890123456789012 > > All the machines at this site share the same home directory. > So I logged in remotely to anther machine and tried to run > an X app, but it was refused. > > I restarted X, but still the same problem. > > I restarted with > startx -auth ~/.Xauthority > > but X refused to run complaining > /a/juno/u1/ra/raines/.Xauthority: ^DO@l^A0^RMIT-MAGIC-COOKIE-1^P^R4Vx^R4Vx^R4Vx^R: not found. > > What am I doing wrong? Sounds like it should work. I did, however, leave out one part of my tale. I started out creating the ~/.Xauthority entry for my machine much like you did. I ended up rebooting my machine twice in all, and at some point it "noticed" I wanted to use ~/.Xauthority and started creating entries automatically upon login. After the *next* time I rebooted (just to be sure the X server was reset; I had no idea how to do it otherwise using HP VUE), the access control worked! The new entries it started creating look like the following: dino.ph.utexas.edu:0 MIT-MAGIC-COOKIE-1 382f5... dino/unix:0 MIT-MAGIC-COOKIE-1 382f5... dino/unix:0 MIT-MAGIC-COOKIE-1 382f5... The only entry I added was the first, but all three always share the same hex key. Dunno why it added it twice. And I've checked; every time I log in now I get a new hex key. (Is this starting to resemble black magic yet?) Maybe this can help, maybe not. Maybe you need to chant and juggle some rubber chickens in front of the console :-). It's stuff like this that makes me wonder if I really understand computers after all.. -- Maurice LeBrun mjl@dino.ph.utexas.edu Institute for Fusion Studies, University of Texas at Austin Faire de la bonne cuisine demande un certain temps. Si on vous fait attendre, c'est pour mieux vous servir, et vous plaire. [menu of restaurant Antoine, New Orleans] From doug@happy.vf.ge.com Mon Nov 15 00:41:17 1993 Newsgroups: comp.lang.tcl,comp.windows.x From: doug@happy.vf.ge.com (Doug Hughes) Subject: Re: FINAL xauth ( on X-Terminals Followup-To: comp.windows.x Nntp-Posting-Host: happy.vf.ge.com Reply-To: doug@happy.vf.ge.com Organization: GE Aerospace - VF Date: Fri, 12 Nov 1993 13:16:43 GMT In article <1993Nov12.084044@zam067.zam.kfa-juelich.de>, zdv145@zam067.zam.kfa-juelich.de (Helmut Schumacher) writes: > Does anyone have/use X-Terminals with Xauthority? > > How must XDM be configured? > > Can xauth be used without using XDM? > > Helmut Schumacher > > hel.schumacher@kfa-juelich.de Well, I don't think this is the right newsgroup (comp.lang.tcl) so I'm cross-posting to comp.windows.x with followup redirected there. Anyway, yes, we use xauth for our NCD xterminals. You have to do to things, you have to have your xauth keys in two different places. 1) /usr/lib/X11/xdm/xdm-keys where entries look like this -Ethernet-00:00:a7:11:c9:c7 0xb0b125abe7cd00 2) and entry in the configuration file (this would be xterminal specific) on our NCD's running 3.1 software the entry looks like this in the ncd's configuration file login-xdm-authentication-key = 0xb0b125abe7cd00 Hope this helps (notice, the two keys are identical. very important. :) ) -- _____________________________________________________________ Doug Hughes System/Net Admin - Martin Marietta Aerospace, Valley Forge, PA doug@happy.vf.ge.com or doug@land.vf.ge.com