Close Some Network Security Holes

As shipped, the SGI is fairly permissive in its networking. Their philosophy appears to be that novices should be able to use their systems and networks immediately, and if you're smart enough to be concerned with network security, you're smart enough to close the holes in the network. I don't necessarily agree with this approach, but I'm sure it cuts down on the number of novice helpdesk calls they get.


XDM is the X Window System Display Manager. It presents a login window (with user-icons, in the SGI case), accepts username and password, and starts the session. It is configurable via files specifying resources, other configuration files, and scripts. As shipped, it has a number of holes...

xhosts +

SGI ships with XDM allowing all hosts access to your X server because it runs xhost + in the XDM session files. This means that anyone on the net can attach to your server and display on, take over, or -- more importantly -- monitor your session (eg: login keystrokes). You should negate this with xhost -.

Edit your system's xdm startup files to comment out the xhost + stuff. Here are the files from Irix 5.3:

cshenton@wirehead> cd /usr/lib/X11/xdm/
cshenton@wirehead> grep -n xhost * 
Xsession:80:/usr/bin/X11/xhost +
Xsession-remote:44:/usr/bin/X11/xhost +
Xsession.dt:159:/usr/bin/X11/xhost +
I change these to say:
/usr/bin/X11/xhost -

It would be smart to then verify this. Log out of the console to restart xdm, then log in again. Telnet to some host for which you have not authorized X11 access to your console. Then launch an xclock or something back to the SGI and make sure that the connection gets rejected. Example, after logging into the console for host `apollo':

cshenton@apollo% telnet
Username: chris

chris@notmyfriend% xclock -display
Error: Can't open display:

Warning: don't do the following!

I found, to my cost, that something in the following X11-oriented recommendations hoses the X server badly: you can't log in -- the X server just restarts. Unfortunately, I haven't had time to determine which one yet. If you do, please send me mail. Sorry...

Do continue with tightening the security by installing tcp_wrappers and a modern version of sendmail, at the end of this document.

xdm-config: authorize

According to the relevant section of the xdm man page, the authorize resource should be on to enforce access authorization to the server. Although this is said to be the default, this is set to off in the /usr/lib/X11/xdm/xdm-config file. You should change this, like:
DisplayManager*authorize:		on

xdm-config: terminateServer

Although not really a security hole, you might as well fix this while you're in the xdm-config file. According to the appripriate part of the xdm man page, this defaults to false. But the server tends to grow without bounds, consuming system memory resources. You should set it to true so that the server restarts, rather than resets, upon logout:
DisplayManager._0.terminateServer:	True
DisplayManager._1.terminateServer:	True
DisplayManager._2.terminateServer:	True
DisplayManager._3.terminateServer:	True

X server shm bug

As mentioned above in the xdm manpage, authorization can be bypassed because of a bug. Workaround it by the following fix to /usr/lib/X11/xdm/Xservers; add the option -shmnumclients 0 to the invocation of the X server:
:0 secure /usr/bin/X11/X -bs -nobitscale -c -pseudomap 4sight \
-solidroot sgilightblue -cursorFG red -cursorBG white \
-shmnumclients 0
(Note: the line above has be split with backslashes for readability).

Deny root login from the network

Most systems these days deny logins by root if they're coming from the network. The idea is that if you want to log in as root, you should do it from the console. Otherwise, you can login over the net as yourself, then use su to become root.

SGI, by default, allows root logins from the net; here's how to fix that. The file /etc/default/login defines lots of login parameters. Here's the relevant part you want to use:

# If defined, only allows root logins on the device specified.
# MUST NOT be defined as either "/dev/syscon" or "/dev/systty"!
Originally, that CONSOLE variable was commented out. You might also want to change the following variable which is defaulted to NO for some strange reason:
# Like PASSREQ, but locks out user if they have no password.

There are other interesting variables there which you may want to play with including ones to log failures, lockout accounts after a certain number of failures, etc.


I like to replace my vendors' sendmail with the UCB Sendmail. It's code has been scrutinized and fixes are made quickly.

TCP wrappers

I install tcp_wrappers on my systems to restrict Internet access to my machines' network services. It's fairly easy to install and I think it stops most of the bad guys at the front door.
Chris Shenton
$Id: close-security-holes.html,v 1.7 1996/06/11 15:28:58 cshenton Exp $