Modern tools.
Traditional dedication.
Home
| Purpose
| Linux
| Products
| Legality
| Special
| Downloads
| Articles
| Contact
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.
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
fiif [ -x /usr/X11R6/bin/kdm-xscreensaver-command ]; then
/usr/X11R6/bin/kdm-xscreensaver-command -exit
fiOK, 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):
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:# 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
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.# 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
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.
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. (-:
Logan High [Utah] students have adjusted well to Linux. “I have to turn off the light to let them know it’s time to go home,” says [Russell] Weeks, who runs the computer lab after school. “Sometimes their parents come in to get them.”
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.