On 07-Dec-98 Lawson A. Whitney wrote:
> You can take a cheap shot at discouraging this sort of thing by
> bracketing the line in /etc/profile (if you use bash) that adds X11
> to the path, like so:
>
> if (tty |grep tty[1-6]); then
> PATH="$PATH:/usr/X11/bin:$OPENWINHOME/bin:/usr/games:."
> fi
>
> Your telnet user can still start X by saying,
>
> /usr/X11/bin/Xinit -- /usr/X11/bin/X
>
> but he probably won't do that just by accident. This will also
> disrupt xdm logins as they are run on a pty same as telnet sessions,
> so xsession or ~/.xsession would have to have the full paths for
> X commands, or fail.
A better solution would be to modify the "startx" script instead. Try adding
the following line to the top of the "startx" script.
tty | grep tty[0-9] && exit
This should cause the script to terminate if it was not ran at the console.
It's still not perfect but should be sufficient with a little enhancement. An
suid wrapper program would be better but may be overly troublesome.
> I was going to suggest xdm, but I found to my horror that once
> someone is logged in to it, _anybody_ on the local machine can
> start X clients by setting DISPLAY and using a full path, even
> by telnet. There's bound to be something in the X security empire
> to deal with this, if only I live long enough to plough through it
> all. It is, after all, X's security problem, not telnet's.
There's definitely a solution for this problem. Several infact. Look in
Xsecurity and the Xserver man page.
Cort
[EMAIL PROTECTED]
