Lean and Mean

FluxBox Minimalistic Desktop PC


This is part of an experiment to use Linux as a kiosk system. 'Kiosk System' can mean a couple of things, but here we assume that it's a computer that runs just one application , a web browser, or a limited, well defined number of applications. That way, the computer can be left unattended, e.g. in public places (public libraries, ... )

One of the appoaches often taken to accomplish this, is to install Windows, then lock it down and present the user with a limited menu-like user interface - often with specilised software (e.g. WinU) to accomplish a lockdown. But that feels a bit like wasting resources and money : you'd have to buy a Windows License for a computer that will hardly be used (just a browser ...), and on top of that you pay for additional software to make it run nothing but that one browser. So we look at it from a different angle : is this something Linux could do, without all the overkill ?

This Fluxbox kiosk is a revamped web terminal / internet PC: In stead of the somewhat old (but effective) fvwm window manager, we use Ubuntu as operating system, with Fluxbox as a window manager. Fluxbox, like fvwm, is a lightweight window manager that can easily be customized by means of legible text configuration files in a well organized directory tree, and Ubuntu follows a fast-paced release cycle so it's easy to keep up to date with newer features in open source software, especially web browers, instant messengers, and media applications.


What do we need ?

To run just a web browser or a limited number of applications (IM, media player, ..), a minimal x-windows system will do. We will set up a base Linux system (install nothing but the operating system), add some x-window components, and install the software we want to offer to our end-users.

Assuming this computer will be unattended, we don't want users to go and play with it, and we definitly don't want users to crack it or try to escalate their privilegues or install their own software so that the machine becomes a zombie or what not - so we will discuss some measures to secure the system.

the base setup

We install nothing but a base system, then add the packages we need / want. Here are instructions to setup a base Ubuntu system. In short, it means you do something like :

	## baseline setup
	wget http://myserver/files/baseline_setup.sh
	chmod 770 baseline_setup.sh
	./baseline_setup.sh

	## install window system	### requires ubuntu 'universe' repo for fluxbox ! ###
	apt-get update
	apt-get -y install xserver-xorg x-window-system-core xterm xdm  fluxbox
	

System requirements : any pc capable of running (text mode) linux + xwindows. Hard disk space : 500 mb (system + software) + swap + room for browser cache /temporary files. Meaning : any old pc with a 1GB Hard disk will do.

xorg will auto-detect your keyboard, mouse, video card, monitor, ... and attempt to configure itself accordingly. If this fails or results in a less then optimal configuration, you can adjust it by modifying the configuration ( dpkg-reconfigure xserver-xorg , or edit the configuration file (/etc/X11/xorg.conf).

configuring the software

As is usual on Linux, applications come with config files that contain default values. A copy of those will end up in the user home directory, in a hidden directory (such as ~/.fluxbox or ~/.mozilla). To force a configuration upon the user, you can

On top of that, you want to prevent the user from modifying the configuration, so you'll make these files read-only or r-x (not writable), or replace them with links to readonly files, mount a read-only directory to the user's home directory, and so on. This might break some applications if they expect to write to the user home (eg firefox). A mechanism to replace the user home directory with a virgin copy at every startup / login might be in order

configuring the GUI

/etc/X11/xdm/Xresources

Here you configure the xdm, the program that handles logins to a GUI environment. It's were you can set a logo to appear on the login screen, change the colours, etc

	xlogin*greeting: CLIENTHOST  - powered by Ubuntu and Debian GNU/Linux
	xlogin*namePrompt: \040\040\040\040\040\040\040Login:
	xlogin*logoFileName: /etc/kiosk/UbuntuLogo.xpm
	
etc/X11/xdm/Xsetup

Here you configure some xdm behaviour and certain aspects of X, like setting a background colour.

(Custom) colors are defined in /etc/X11/rgb.txt. It maps RGB values to color names. You can then use these names in X and fluxbox configuration files to set colors (background, fonts, borders, ...)

	220 180 120		ubuntu_beige
 	60  20   0		ubuntu_brown
	

Xsession

The Xsession file starts an X session, i.e. it is used when the user logs in through xdm. Therefore, we can use it to start fluxbox, by inserting the statement startfluxbox in to it.

You can either use /etc/X11/Xsession (systemwide default) or /home/user/.Xsession. Or you can replace /home/user/.Xsession by a link to a read-only file (possibly /etc/X11/Xsession) so the user can not change it.

	ln -s /etc/kiosk/Xsession /home/kioskuser/.Xsession
	

Xsession can be used to run programs at X startup, but fluxbox also itself also lets you do that, so we only put "startfluxbox" here, and let fluxbox handle the rest. It makes for a cleaner configuration. Xsession might be the place where you have a copy or rsync command to move virgin config files (including a clean .fluxbox directory) into the user home directory to undo any changes the user may have made.

fluxbox configuration

All user-specific fluxbox configuration is in /hime/user/.fluxbox. This could be a link to a read-only directory elseware, eg /etc/kiosk/fluxbox.
The .fluxbox directory should at least contain the following files :

startup
Script that runs when fluxbox starts. It sets a number of configuration settings, and can be used to start applications - especially those that you want running in the background (&).
init
basic configuration + references to other config files. You could use this to point to config files outside the user home.
keys
meant to contain keymappings. By making it an empty file, the system defaults are overwritten and no key mappings are active.
slit
defines and configures side bars on the desktop. We make it an emty file, but as the file exists, it overrides the system defaults. The result is : no side bars.
style
defines the "style", "theme" or "look" of the desktop. A style file is created by copying a sample style from the /usr/share/fluxbox/style directory and referencing the copy from the init file. You can then apply changes to it at will.
menu
Defines the main "start" menu that appears when you click anywhere on the desktop. Edit it so it only contains those apps you want the kiosk user to have access to.
windowmenu
Defines the window menu that appears when you click a window's title bar and offers items to close / moce / ... the window. Replace it with an emty file to disable the menu and limit the user's ability to mess with the windows (eg if you want to impose 1 application on 1 window with fixed size and position): lege file om windowmenu te disablen (move, close, ...). Althoug you can hide the title bar by setting the application (in apps) with [Deco]{NONE}, the menu remains available if the user clicks at the edge of the window, so if you want to disable it, you need to have this empty file.

autostart (starting an application as soon as fluxbox starts) can be implemented in .fluxbox/startup script of via the [startup] sectie in /fluxbox/apps

menu file

	[begin] (Fluxbox)
   		[exec] (Firefox Web Browser) {firefox} 
   		[exit] (Exit)
	[end]
	

apps file

	[startup] {firefox}
	[app] (firefox)
		[Dimensions]  (WINCENTER) {1024 768}
        	[Position]    {0 0}
		[Deco] {BORDER}
	[end]
	

partial sample init file

	session.appsFile:	~/.fluxbox/apps
	session.keyFile:	~/.fluxbox/keys
	session.menuFile:	~/.fluxbox/menu
	session.screen0.toolbar.visible:	false
	

Applications

Set preferences to the applications and try to lock them by setting their config files not writable. This may break some applications. Eg. Firefox expects the ~/.mozilla directory and certain files in it to be writable, and it will fail to start otherwise.

system administration

If you have installed an ssh server (see baseline), you can do your system administration from a remote workstation, by ssh. This should allow you at least a shell session, but you can also set it up so that you can work in a graphical environment remotely (see a href="../linux/xremote.htm">Remote Desktops).

Alternatively, you can change the default runlevel to 3 (in /etc/inittab) and disable the X startup scripts in rc2.d (runlevel 2). Now, the system will automatically boot to runlevel 3 for the end users - root can boot init 2 for a command prompt and no worries. However, this requires you review /boot/grub/menu.list to make sure the boot menu is visible and allows you to specify boot parameters. You then also require a grub password to prevent other users from doing the same.

You might consider removing the tty's from /etc/init.tab so that a user can not drop to a console by pressing ALT F1, F2, .... setting the login shell to /bin/true might also be a good idea to prevent shell access. Make sure you can still do system administration (eg via ssh).

example

A locked-down Firefox on a minimal FluxBox desktop, used as an online Pyblic Cartalogue browser for tha Antwerp Public Library.
fluxbox and firefox as a, online public catalogue for the Antwerp Public Library

Things to do ...

Some considerations : make sure that firefox functionality is limited (e.g. don't allow browsing the filesystem) : Firefox lockdown. You also want to consider setting a BIOS password, setting the boot-up sequence s that booting from external media is prohibited, and so on. You may want to apply additional filesystem security such as reduce the number of world-readable files, access to shells, and so on.

Check Out


Koen Noens
June 2007