Dave Heinemann

Locking Down Ratpoison

If you use the Ratpoison window manager, you've probably noticed that it doesn't come with any provisions for locking the screen, unlike full desktop environments such as KDE and Gnome. This tutorial will show you how to use Xlock and XDM to prevent malicious users from rm -rf /ing your drive. :)

The first step will be to set up Xlock, a screen locking tool, then the XDM display manager, to prevent Xlock from being circumvented by switching virtual terminals (e.g. with Ctrl+Alt+F1) or killing the X server (with Ctrl+Alt+Backspace). These tools are fairly lacking in the eye-candy department, but they do the job and do it well. It's also fairly easy to switch xdm for something a little nicer like KDE's KDM.

This tutorial is written for people running Ratpoison on Slackware 13.37, but it should apply to all other Slackware window managers, and should apply in principle for other Linux distributions.

Xlock

Xlock is a screen locking tool available out of the box on Slackware. It isn't very pretty, but it works. Our goal here is to

  1. Configure Xlock
  2. Write a shell script
  3. Bind the shell script to a Ratpoison key combination

Configuration

I personally use Xlock with this command:

% xlock -mode blank -timeout 1 -mousemotion -usefirst +description

Go ahead and give it a try. If you want to customize it a bit, visit the man page. There's a rather long list of available screensavers to try, if you're into that sort of thing.

Shell script

Now we will make a shell script out of the Xlock command, so it can easily be called from the command prompt and bound to a Ratpoison key combination.

Create a file called something like ~/.screenlock, and write this, or whatever your preferred Xlock command is:

#!/bin/sh
xlock -mode blank -timeout 1 -mousemotion -usefirst +description

Then run % chmod +x ~/.screenlock to make it executable. Try running it to confirm everything is working.

Ratpoison bindings

Once the shell script is working, we'll want to bind it to a Ratpoison key combination, so it can easily be called later. I like to use Ctrl+t, l to lock my screen, so I added this line:

bind l exec ~/.screenlock

Either restart Ratpoison (Ctrl+t, :restart) or execute Ctrl+t, :bind l exec ~/.screenlock to activate the change and confirm it's working. You should now be able to lock your screen at any time with Ctrl+t, l.

At this point, your computer may be secure enough around non-Linux users, but anyone with a little experience can circumvent xlock and gain console access by killing the X server directly (with Ctrl+Alt+Backspace) or changing to the original virtual terminal (usually Ctrl+Alt+F1) and killing X from there. Save anything you are currently working on and give this a try. When you're ready, we will configure XDM and fix it.

XDM

XDM is a basic (and kinda ugly) display manager that comes standard with Slackware. KDM (KDE's display manager) is also available, but I'm not a fan.

Display managers like XDM will prevent people from gaining access to your terminal session by not using the usual ttys, and falling back to the display manager's login prompt with X is killed. If X is killed, you'll still lose unsaved work, but it shouldn't be possible to access your terminal session any more.

To set up XDM, we will

  1. Change the default runlevel in /etc/inittab
  2. Force the use of XDM in /etc/rc.d/rc.4
  3. Change the default session type in /etc/X11/xdm/xdm-config
  4. Make /etc/X11/xdm/Xsession use the user's .xinitrc file by default
  5. Make a couple of cosmetic changes to /etc/X11/xdm/Xsetup_0 and /etc/X11/xdm/Xresources.

Changing the default runlevel

Edit /etc/inittab and change the line that reads id:3:initdefault: to id:4:initdefault:.

Forcing use of XDM as display manager

By default, Slackware prioritizes the use of GDM (if installed) and KDE over XDM. To fix this, edit /etc/rc.d/rc.4 and comment out the GDM and KDE lines, so that only XDM remains:

## Try to use GNOME's gdm session manager.  This comes first because if
## gdm is on the machine then the user probably installed it and wants
## to use it by default:
#if [ -x /usr/bin/gdm ]; then
#  exec /usr/bin/gdm -nodaemon
#fi
#
## Someone thought that gdm looked prettier in /usr/sbin,
## so look there, too:
#if [ -x /usr/sbin/gdm ]; then
#  exec /usr/sbin/gdm -nodaemon
#fi
#
## Not there?  OK, try to use KDE's kdm session manager:
#if [ -x /opt/kde/bin/kdm ]; then
#  exec /opt/kde/bin/kdm -nodaemon
#elif [ -x /usr/bin/kdm ]; then
#  exec /usr/bin/kdm -nodaemon
#fi

# If all you have is XDM, I guess it will have to do:
if [ -x /usr/bin/xdm ]; then
exec /usr/bin/xdm -nodaemon
elif [ -x /usr/X11R6/bin/xdm ]; then
exec /usr/X11R6/bin/xdm -nodaemon
fi

Now if you reboot, you should be greeted by the XDM login screen, rather than the usual console login prompt.

Changing the default session type

However, you'll notice that once you log in, the system-default window manager is loaded (whatever's in /etc/X11/xinit/xinitrc) rather than the user default. For some reason, XDM in Slackware is set to ignore the user's xwmconfig choice.

The best way to fix this seems to be by editing /etc/X11/xdm/xdm-config and /etc/X11/xdm/Xsession to use the user's own ~/.xinitrc, although Xsession advises that this isn't recommended.

Open /etc/X11/xdm/xdm-config, find the line that reads DisplayManager*session: /usr/lib/X11/xdm/Xsession and change it to DisplayManager*session: /usr/lib/X11/xdm/Xsession userdefault

Don't mind that it points to /usr/lib/; it's symlinked. Save that, then open /etc/X11/xdm/Xsession and add a userdefault option to the case statement so that it looks like this:

# If a particular session type was requested in $1, start that session:
case "$1" in
failsafe)
xsetroot -solid SteelBlue
exec xterm -geometry 80x24-0-0
;;
userdefault)
if [ -x $HOME/.xinitrc ]; then
exec $HOME/.xinitrc
else
exec /etc/X11/xinit/xinitrc
fi
;;
kde)
exec startkde
;;
gnome)
exec gnome-session
;;
openwin)
exec olvwm
;;
fluxbox)
exec fluxbox
;;
fvwm2)
xsetroot -solid SteelBlue
exec fvwm2
;;
fvwm95)
xsetroot -solid SteelBlue
exec fvwm95
;;
blackbox)
exec blackbox
;;
xfce)
exec /etc/X11/xinit/xinitrc.xfce
;;
windowmaker)
exec /etc/X11/xinit/xinitrc.wmaker
;;
afterstep)
exec afterstep
;;
enlightenment)
exec enlightenment
;;
twm)
#xclock -geometry 50x50-1+1 &
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &
#xterm -geometry 80x66+0+0 -name login &
xsetroot -solid SteelBlue
exec twm
;;
esac

The new userdefault option will tell XDM to load up whatever the user has set up in ~/.xinitrc, which is usually controlled by the xwmconfig program. chmod your ~/.xinitrc to executable if you haven't already (% chmod +x ~/.xinitrc), the log out and back in again to confirm that your preferred window manager (probably Ratpoison) is loading. If it doesn't work, double-check the contents of your ~/.xinitrc, and make sure it's set up properly. If the wrong WM has somehow ended up in there, re-run xwmconfig under your own account.

Cosmetic changes

You're pretty much done now, but there are still a couple of optional changes. You may have noticed that by default, XDM uses an ugly blue background and tiny mouse cursor, both of which will carry over into Ratpoison after logging in.

You can fix the background colour by editing /etc/X11/xdm/Xsetup_0 and changing the line with 'SteelBlue' to just 'black':

# If the nifty KDE background loader is around, use it:
if [ -x /opt/kde/bin/kdmdesktop ]; then
/opt/kde/bin/kdmdesktop
elif [ -x /usr/bin/kdmdesktop ]; then
/usr/bin/kdmdesktop
else
#/usr/bin/xsetroot -solid SteelBlue
/usr/bin/xsetroot -solid black
fi

And you can get rid of that hideous cursor by editing /etc/X11/xdm/Xresources and commenting out the line right at the top that reads 'Xcursor.theme: whiteglass'.

And we're done! If you log out and back in again, you should be greeted with the XDM login screen (with a nice background and normal cursor). When logging in, your preferred window manager should be loaded (Ratpoison, for most people reading this guide). You'll be able to lock your screen with Ctrl+t, l, and if you hit Ctrl+Alt+Backspace or switch to another virtual terminal, it shouldn't be possible to gain access to your terminal session any more.

#Linux #Slackware