Tk SEND Command
Malur Narayan
I've been trying to use Tk's SEND command to communicate between Tk apps,
but without much success.
It seems to require X-auth style security. Is there any way to use the SEND command
with Xhost type of security.
Here are the error messages:
% winfo interps
browse widget wish treesh
% send treesh {button .a -text "hi"; pack .a}
X server insecure (must use xauth-style authorization); command ignored
Thanks
--
Malur A. Narayan
Senior Information Developer
Transmission Information and Learning Products
Bell-Northern Research Ltd., Ottawa, Canada mnar...@bnr.ca
Rajiv Muradia
|> Hi:
|> I've been trying to use Tk's SEND command to communicate between Tk apps,
|> but without much success.
|> It seems to require X-auth style security. Is there any way to use the SEND command
|> with Xhost type of security.
I don't know the answer to your question but you do have an option to rebuild
wish without the xauth authorization.
|>
|> Here are the error messages:
|>
|> % winfo interps
|> browse widget wish treesh
|> % send treesh {button .a -text "hi"; pack .a}
|> X server insecure (must use xauth-style authorization); command ignored
|>
|> Thanks
|> --
|> Malur A. Narayan
|> Senior Information Developer
|> Transmission Information and Learning Products
|> Bell-Northern Research Ltd., Ottawa, Canada mnar...@bnr.ca
--
Rajiv
Tuan Doan
>Hi:
>I've been trying to use Tk's SEND command to communicate between Tk apps,
>but without much success.
>It seems to require X-auth style security. Is there any way to use the SEND command
>with Xhost type of security.
>
>Here are the error messages:
>
>% winfo interps
>browse widget wish treesh
>% send treesh {button .a -text "hi"; pack .a}
>X server insecure (must use xauth-style authorization); command ignored
Unless you do -DTK_NO_SECURITY you will have to live with using xauth.
>Thanks
>--
>Malur A. Narayan
>Senior Information Developer
>Transmission Information and Learning Products
>Bell-Northern Research Ltd., Ottawa, Canada mnar...@bnr.ca
Regards,
__ __/ / / __ / | / Tuan T. Doan
/ / / / / / | / IEC Layer Testing and Advance Technology
/ / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871
__/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871
"It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575
Internet: td...@bnr.ca Fax: 6-444-3716/214-684-3716
Bennett Todd
>SEND command with Xhost type of security.
Yup. Easy. Just recompile the interpreter [or at least the tkSend.c module]
with TK_NO_SECURITY defined. This will revert to the old behavior, where the
receiving end of the ``send'' protocol doesn't check for security.
Then, to see why the security was added, log in to your machine (the one
that was named in xhost(1)) as someone else, and do something like the
following:
wish
% send treesh {exec touch AAA___I_COULD_HAVE_DELETED_YOUR_HOME}
% send treesh {exec touch AAA___DIRECTORY_BY_RUNNING_RM_INSTEAD_OF}
% send treesh {exec touch AAA___TOUCH}
The point is that xhost(1) isn't particularly tight security, unless all
your machines are strictly single-user. Most computers running Unix, TCP/IP,
and X are _not_ single-user. Tk expands the vulnerability significantly,
since anyone who can connect to your X server can send commands to your Tk
interpreter, and those commands can run shell commands. So the security
enhancement under #ifndef TK_NO_SECURITY is really pretty important. If you
want to use send, it's worth your while to get xauth(1)-based authentication
working.
-Bennett
b...@sbi.com
Greg Wesson
>If you want to use send, it's worth your while to get xauth(1)-based
>authentication working.
How does one go about doing that. I read the man page, but it really wasn't
much help. Is this something that the WGA has to do, or can I do it myself?
Greg
--
+ -- Gregory J. Wesson (lanp...@bnr.ca). + -- + Phone Esn 393-9193 -- +
The opinions in this post are mine, and do not reflect those of BNR.
Quote : "Did you come here to play Jesus? I did."
- One, U2
Peter da Silva
> Then, to see why the security was added, log in to your machine (the one
> that was named in xhost(1)) as someone else, and do something like the
> following:
> wish
> % send treesh {exec touch AAA___I_COULD_HAVE_DELETED_YOUR_HOME}
> % send treesh {exec touch AAA___DIRECTORY_BY_RUNNING_RM_INSTEAD_OF}
> % send treesh {exec touch AAA___TOUCH}
> The point is that xhost(1) isn't particularly tight security, unless all
> your machines are strictly single-user.
The problem is that "send" feeds into the TCL interpreter. Most cases you
don't need this sort of flexibility. It'd have been better to have a
designated receiver proc:
accept {handle_send_events {%s}}
proc handle_send_events string {
puts stdout string
return 1
}
Then you could implement the current policy:
proc handle_send_events string {
return [eval $string]
}
Without having to have everything hanging out there. Even with Xauth, you're
open to a trojan horse. Especially if you're a system administrator and run
some programs as root. I normally only have a couple of root windows at most,
and run most everything with general user permissions.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
Thomas Kwong
>The point is that xhost(1) isn't particularly tight security, unless all
>your machines are strictly single-user. Most computers running Unix, TCP/IP,
>and X are _not_ single-user. Tk expands the vulnerability significantly,
>since anyone who can connect to your X server can send commands to your Tk
>interpreter, and those commands can run shell commands. So the security
>enhancement under #ifndef TK_NO_SECURITY is really pretty important. If you
>want to use send, it's worth your while to get xauth(1)-based authentication
>working.
>-Bennett
>b...@sbi.com
For some unknown reasons, I couldn't get the xauth-style way working.
BTW, I followed the Xauthority instructions file from harbor ftpsite.
It's much easier to just recompile without security enforced.
-Tom
--
Thomas Kwong (tomk...@netcom.com) __&__ |-
Wilshire Associates, Incorporated. ___\/__ __]
Office: (310)451-3051 Ext. 227 [--] [
Home : (310)641-8818 Ext. 911 )==] [=
) .| [__\
Scott Schwartz
It's much easier to just recompile without security enforced.
So is posting your password to the net.
My prediction: TK_NO_SECURITY is going to be the way the next internet
worm nails your ass.
John: please get rid of it while there is still time.
Randal L. Schwartz
Scott> tomk...@netcom.com (Thomas Kwong) writes:
Scott> It's much easier to just recompile without security enforced.
Scott> So is posting your password to the net.
Scott> My prediction: TK_NO_SECURITY is going to be the way the next internet
Scott> worm nails your ass.
Scott> John: please get rid of it while there is still time.
Yeah, really, for me it was as simple as adding:
COOKIE=`perl -e 'srand($$^time); for (1..4) {printf "%08x",rand(2**32-1);}'`
: ${COOKIE=ffffffffffffffffffffffffffffffff}
HOST=`hostname`
xauth add $HOST/unix:0 . $COOKIE
xauth add $HOST:0 . $COOKIE
xauth add localhost:0 . ffffffffffffffffffffffffffffffff
# don't let xrsh use xhost
# XRSH_AUTH_TYPE=none; export XRSH_AUTH_TYPE
exec X :0 -auth $HOME/.Xauthority
as my .xserverrc file. (The invariant localhost cookie is necessary
because I may have multiple servers all on at the same time, and it
was otherwise writing over my .Xauthority file with bad new numbers.)
Yeah, Perl in the TCL group again. Sorry. :-)
Just another Perl hacker and TCL newbie,
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@ora.com> Snail/FAX: (Call) aka: <mer...@teleport.com>
Phrase: "Welcome to Portland, Oregon ... home of the California Raisins!"
Kevin B. Kenny
In article <SCHWARTZ.94...@roke.cse.psu.edu>, schw...@roke.cse.psu.edu
(Scott Schwartz) writes:
|> My prediction: TK_NO_SECURITY is going to be the way the next internet
|> worm nails your ass.
|>
|> John: please get rid of it while there is still time.
No, please don't!
I run on a corporate internal network behind a firewall. Essentially,
all the machines in my xhost list are trusted, and all the users of
those machines (most of which are single-user workstations) are trusted.
Moreover, many of my users still have X11R3 applications that haven't
been recompiled. These users have to use xhost security, since the R3
library doesn't present authentication to the server. (On one of my
machines, I have vendor-supplied versions of utilities like xterm that
fail to present authentication, and I have yet to determine why.)
I don't have an easy way out; disabling the security features for now
and being careful about my host table is the best that I can do.
73 de ke9tv/2, Kevin KENNY GE Corporate R&D, Niskayuna, New York, USA
Scott Schwartz
I run on a corporate internal network behind a firewall.
Ah, the soft underbelly protected only by thin armor. Good luck---
you'll need it.
Moreover, many of my users still have X11R3 applications that haven't
been recompiled.
So recompile them. Did you replace sendmail after the worm?
I don't have an easy way out; disabling the security features for now
and being careful about my host table is the best that I can do.
If John removes the #ifdef, then knowledgable folks will still have
source and can hack Tk any way they want. That's the point: "no
security" should be at best an undocumented local hack, not a supported
feature.
David Herron
In the environment here we have very FEW systems sharing the same filesystem.
Even though there are lots of Sun servers around (ergo, lots of NFS
availability) $HOME is shared between few of them. $HOME on my workstation
is not even the same $HOME as the main file server I use.
Therefore the trick of putting .Xauthority in $HOME does not work. X
clients on remote systems do not have the same $HOME/.Xauthority as on my
workstation making things more difficult.
What advice might there be for this situation?
David
<- David Herron <da...@twg.com> (work) <da...@davids.mmdf.com> (home)
<-
<- Real life involves many economies where the choices and gains
<- are more than some visible exchange involving money.
Bennett Todd
Greg Wesson <lanp...@bcarh17c.bnr.ca> wrote:
>In article <2o1n8q$q...@sbi.sbi.com> b...@std.sbi.com (Bennett Todd) writes:
>>If you want to use send, it's worth your while to get xauth(1)-based
>>authentication working.
>
>How does one go about doing that. I read the man page, but it really wasn't
>much help. Is this something that the WGA has to do, or can I do it myself?
You can do it yourself. What you need is some code in a script to kick off
the X server. In general, you need to stuff a cookie into .Xauthority, then
start up X with an argument telling it to use that file. I append after my
sig a helpful note by Vivek Khera describing how to make this work.
-Bennett
b...@sbi.com
From: kh...@cs.duke.edu (Vivek Khera)
Newsgroups: comp.lang.tcl
Subject: Re: HELP: xauth?
Message-ID: <KHERA.93O...@thneed.cs.duke.edu>
Date: 6 Oct 93 13:44:37 GMT
Organization: Duke University CS Dept., Durham, NC
>>>>> "SD" == Scott Deifik <sco...@amgen.com> writes:
SD> I've seen some stuff about xauth in this newsgroup tk3.3 but I
SD> didn't get a chance to read it. I just can't seem to get send to
SD> work (ie. I can't get xauth to work). How do you do it? I am
SD> working on display scott:0.0 and I ran the command: xauth add
SD> scott:0.0 . 00 I wasn't sure what the hex number shoud be, so I
SD> just used "00".
Here's my standard blurb on using xauth. This has nothing
specifically to do with tcl or tk, so I've redirected followups to the
appropriate newsgroup.
By the way, using "xauth +" basically opens up your workstation to
*everyone* on the network to which you are connected. If you are on
the Internet, you really open up a can of worms...
Author: Vivek Khera <kh...@cs.duke.edu> -*- 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 +<machine>
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.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Gradual Student/Systems Guy Department of Computer Science
Internet: kh...@cs.duke.edu Box 90129
RIPEM/PGP/MIME spoken here Durham, NC 27708-0129 (919)660-6528
Scott Schwartz
Therefore the trick of putting .Xauthority in $HOME does not work. X
clients on remote systems do not have the same $HOME/.Xauthority as on my
workstation making things more difficult.
Yes, X makes things more difficult, but we already knew that. :-)
I'm in the same situation. My approach is to copy the authority
information to each machine that needs it after I log in. If you can
rsh without typing a password (via kerberos, .rhosts, or whatever) then
the xauth manpage suggests the following:
xauth extract - $DISPLAY | rsh other xauth merge -
In other cases I do the rlogin and then paste the right stuff into the
window to prime that machine for X. To make that easier, I first run
the following program, which computes all the right stuff (DISPLAY,
xauth, launch an xterm, and quit the rlogin session) and then puts it
into the primary selection, and echos it, so I can easily paste or rsh
its output.
#!/bin/sh
# authother -- print commands which prepare the other machine for X
: ${HOST:=`hostname`}
HOST=`nslookup $HOST | awk '/Name: / { print $2 }'`
AUTH=`xauth list $HOST:0` || {
echo "authother: cannot read xauth list $HOST:0" 1>&2;
exit 1;
}
cmd="
DISPLAY=$HOST:0;
xauth add $AUTH;
xterm & exit
"
xselection -replace PRIMARY "$cmd"
echo $cmd
Jimmy Aitken
>In article <1994Apr8.1...@bcarh54a.bnr.ca>,
>Greg Wesson <lanp...@bcarh17c.bnr.ca> wrote:
>>In article <2o1n8q$q...@sbi.sbi.com> b...@std.sbi.com (Bennett Todd) writes:
>>>If you want to use send, it's worth your while to get xauth(1)-based
>>>authentication working.
>>
>>How does one go about doing that. I read the man page, but it really wasn't
>>much help. Is this something that the WGA has to do, or can I do it myself?
>
>You can do it yourself. What you need is some code in a script to kick off
>the X server. In general, you need to stuff a cookie into .Xauthority, then
>start up X with an argument telling it to use that file. I append after my
>sig a helpful note by Vivek Khera describing how to make this work.
>
>-Bennett
>b...@sbi.com
This is fine and I can see how to do this if I start up an X session
directly. However, how do you do this if when you turn on your X terminal,
you get an xdm login prompt? Ay help would be gratefully received.
Thanks,
Jimmy
--
ji...@pyramid.com -m------- Jimmy Aitken
ji...@pyra.co.uk ---mmm----- Pyramid Technology Ltd
..!mcsun!uknet!pyrltd!jimmy-----mmmmm--- Pyramid House, Solartron Rd
(+44) 252 373035 -------mmmmmmm- Farnborough, Hants GU14 7PL, ENGLAND
`Rrrrum Ti-Tum Ti-Tum Ti-Tum, Rrrrum Ti-Tum Ti Ta-Ta,
Rrrrum Ti-Tum Ti-Tum Ti-Tum, Rrrrum Ti Tiddly Ta...'
Peter Whaite
Jimmy Aitken <ji...@pyra.co.uk> wrote:
>
>This is fine and I can see how to do this if I start up an X session
>directly. However, how do you do this if when you turn on your X terminal,
>you get an xdm login prompt? Ay help would be gratefully received.
My experience is with SGI machines (IRIX 4.0.x) but it probably applies
generally.
When you start a session under xdm it puts a cookie in your .Xauthority and a
matching cookie in the X server for you. If its not doing this then you have
to find the xdm-config file (on SGI machines its in
/usr/lib/X11/xdm/xdm-config) and edit it to turn authorization on (it will be
obvious and the xdm man page has more). Once this is done kill off the X
server and xdm should start up a new session with authorization enabled. If
anyone knows a more elegant way to reinitialize the server with authorization
I'd love to know.
You should also do 'xhost -'. I think xauth doesnt work if xhost access is
enabled (which it is by default on IRIX 4.0.x).
Good luck.
Bennett Todd
>In the environment here we have very FEW systems sharing the same filesystem.
> Even though there are lots of Sun servers around (ergo, lots of NFS
>availability) $HOME is shared between few of them. $HOME on my workstation
>is not even the same $HOME as the main file server I use.
>
>Therefore the trick of putting .Xauthority in $HOME does not work. X
>clients on remote systems do not have the same $HOME/.Xauthority as on my
>workstation making things more difficult.
Well, if your net is set up so that most of the machines you use can get at
your home directory via NFS (even if they have a different local $HOME), and
if you always run your X server from one ``primary'' home, then a symlink in
your other homes pointing to your primary home/.Xauthority should do you. I
get a lot of mileage out of that.
If not, then you need to set up a hack. One attempt at the be-all and
end-all of hacks is xrsh, found in contrib/clients/xrsh with R5, and I
presume it's in export.lcs.mit.edu:contrib/ though I can't seem to connect
there at the moment.
If your needs are different, then maybe you could make a hack of your own;
trivially, you could try to write a script that extracts your cookie with
xauth(1), then builds a command to rsh over that uses xauth(1) on the far
end to stuff the cookie in, then fires up whatever program. Worst comes to
worst, you can _always_ solve the problem with expect(1)! And the _really_
cool thing is, whatever performance hit expect(1) inflicts will be
immeasureably small compared to network connection setup times --- joy!
-Bennett
b...@sbi.com
Ken Raeburn
I'm in the same situation. My approach is to copy the authority
information to each machine that needs it after I log in. If you can
rsh without typing a password (via kerberos, .rhosts, or whatever) then
the xauth manpage suggests the following:
xauth extract - $DISPLAY | rsh other xauth merge -
In other cases I do the rlogin and then paste the right stuff into the
window to prime that machine for X.
That's what network spy programs are for. :-)
NFS is vulnerable to them as well.
I use Kerberos rcp -- "rcp -x" for encrypted transfer -- between
sites. Don't have any suggestions for fixing NFS.
--
~~
~~ Ken Raeburn ~~ Cygnus Support / Cambridge, MA