CyberKnights

Modern tools.
Traditional dedication.

Screensaver for KDM HOWTO (v0.0)

The Problem

You can't run a screensaver over KDM without doing “xhost +” and effectively dropping your X server's drawers for anyone with network access to it. Sniffed passwords, shot screens, you name it, the potential for devastation is immense. I know it’s true, ’coz Jamie Zawinski said so.

JWZ does indeed have a point. However, the X server already takes calls from KDM itself, the implication being that the security holes are going to be related to the hacks rather than to xscreensaver proper. In fact, if you run xscreensaver as root (ie, from KDM), it immediately switches UIDs to nobody:nobody and the X server takes offense at this and refuses to play.

The obvious solution is to mangle xscreensaver so it doesn’t do that, and take care when specifying screensaver hacks. So... out with the meat saw, and in with the “#if 0” statements in two places (drive/setuid.c for startup and driver/exec.c for launching hacks), a recmpile, and it works. To avoid the terrible risk of someone inadvertantly running the ravaged version of xscreensaver, I called it kdm-xscreensaver (and the corresponding command tool kdm-s named screensaver-command); also also chmod 500'ed these executables so nobody else would be able to run them.

The Framework

This may also work with other DM’s (xdm, gdm etc), but I’ve not tried it. When KDM throws the login thingy (“the greeter”) up, it executes the Xsetup script. On my Mandrake 10.0 boxen, this is /etc/X11/xdm/Xsetup_0, which needs the following stanza added to it:

if [ -x /usr/X11R6/bin/kdm-xscreensaver ]; then
        /usr/X11R6/bin/kdm-xscreensaver &> /tmp/xsc.log &
        /usr/X11R6/bin/kdm-xscreensaver-command -activate
fi

When the greeter has decided that a user's credentials are OK, and goes to log it in, it runs Xsession (in the same directory). Losing access to the display (when it changes ownership) should be enough to permanently discourage xscreensaver, but we make sure by adding this stanza to Xsession:

if [ -x /usr/X11R6/bin/kdm-xscreensaver-command ]; then
        /usr/X11R6/bin/kdm-xscreensaver-command -exit
fi

The Screensaver

OK, that takes care of getting xscreensaver running. Notice that I've carefully spelled out the full pathnames to the executables and everything else, which makes it harder for an attacker to inject their own executable earlier in the $PATH.

Since xscreensaver is running as root, it will read its configuration from the file /root/.xscreensaver — which is not a problem on any of my systems, where nobody logs in as root on the GUI. However, if it is a problem for you, just do a little more surgery on xscreensaver to force it to read config from a predefined place, or if you want to avoid having two xscreensavers, add an option to have it read config from elsewhere and supply that option in Xsetup.

This application required only a slideshow, so I chose chbg as a hack. The xscreensaver configuration for this looks approximately like this (with the critical parts bolded):

# XScreenSaver Preferences File
# Written by xscreensaver-demo 4.14 for root on Tue Jul 27 18:38:10 2004.
# http://www.jwz.org/xscreensaver/

timeout:        0:05:00
cycle:          0:10:00
lock:           False
lockTimeout:    0:00:00
passwdTimeout:  0:00:30
visualID:       default
installColormap:    True
verbose:        False
timestamp:      True
splash:         False
splashDuration: 0:00:05
quad:           False
nice:           10
memoryLimit:    0
fade:           True
unfade:         False
fadeSeconds:    0:00:03
fadeTicks:      20
captureStderr:  False
ignoreUninstalledPrograms: True
font:           *-medium-r-*-140-*-m-*
dpmsEnabled:    True
dpmsStandby:    2:00:00
dpmsSuspend:    2:00:00
dpmsOff:        4:00:00
grabDesktopImages:  False
grabVideoFrames:    False
chooseRandomImages: True
imageDirectory: /path/to/slides
mode:           one
selected:       1
programs:                                                                     \
  default-n:          "Slides"  chbg -xscreensaver -scenario /path/to/config   \n\

pointerPollTime:    0:00:05
windowCreationTimeout:0:00:30
initialDelay:   0:00:00
sgiSaverExtension:  True
mitSaverExtension:  False
xidleExtension: True
procInterrupts: True
overlayStderr:  True

Having xscreensaver refuse to lock is important because it assumes that if it’s running as root it’s been SUIDed, and isn’t sure which original user ran it. The file at /path/to/config looks soemthing like this:

# this is automaticaly generated chbg scenario file

OutputToFile: false
Blank: false
Speed: 100
Tooltips: true
Recurse: true
InWindow: false
Randomize: true
CycleBlank: false
MinPictureSize: 0
FractalIterations: 30
RectSize: 16
Screensaver: false
XScreensaver: true
Enlightenment: false
RememberLast: true
Sort: false
ForceNautilus: false
SendExpose: false

UseGradients: false
UseTiles: false
UseBanners: false
Gradient: 0
BackgroundColor: #001cff
BackgroundColor2: #ffffff
RandomizeColors: false
RenderingMode: maximize
Interval: 0.20
Effect: 0
Shader: 0

Picture: /path/to/images

The /path/to/images directory is writeable only by root, so if any PNG or any further JPEG vulnerabilities are discovered, an unpriviledged attacker won’t be able to employ them here. The “Interval” setting is the minutes.seconds between slides, and “Maximize” means that the slides will be scaled up until one axis or the other hits an edge.

Two “convenience” options are Effect, set to 0 here so the slides are just dropped into place rather than wiggled, spiralled, scanned, rained or whatever, and RememberLast, which ensures that the saver isn't constantly being restarted from the same spot. Randomize isn’t very, so this would rapidly become irritating.

Flaws

Because KDM sizes the keyboard, you have to wiggle the mouse to get rid of the screensaver.

KDM is big and ugly enough now to have a "Screensaver" option in kdmrc which names a (file containing a) list of hacks to run. If done right (ie by handing down proper X authentication tokens to the hacks) these can be run as nobody or a purpose-made harmless user, a great saving in security sweat. If any of the KDE crew read this, yes, it is a hint. (-:

ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THE SOFTWARE PRODUCT.

They also assume an economic liability of $5 or software price, unless forced by some applicable law.

Is this the kind of customer support that makes proprietary software a better choice for business use? — nicke on LWN

Last changed: 09-Sep-2008 10:29:30 Find out who links to this page. Verify for yourself that this page is pure, standard HTML, not Ruby.

If you would like us to read email for USD$1000 per page, payable in advance, send it here.