Lockdown

A linux locked down kiosk system



This is part of an experiment to use Linux as a kiosk system.
What most kiosks have in common is that you don't want the users to modify any settings, so you'll have to pay some extra attention to locking down the system

Here's an overview of actions you might want to consider ... It partially assumes a Ubuntu (Gnome) desktop, but the general principles can be applied to other distributions and desktop environments as well.


BIOS

We do not want users to boot from removable media such as CD-rom or USB drives, as this would allow them to boot into an operating system (live CD's, setup media, ...) that completely circumvent the lockdown. We do not want to prevent the user from rebooting per se : if we did that, they may be tempted to just pull the plug to shutdown and reboot, possibly damaging the filesystem.

In stead, set the BIOS so that the system can only boot from the hard disk, and protect access to the bios with a password.

Secure the boot menu

GRUB can be used to pass boot parameters that would allow the user to boot in maintenance mode or switch to a runlevel where your GUI lockdown is not active. Setting a password on GRUB prevents this. The password does NOT, however, prevent any user to select 'recovery mode' (=root access) from the menu.

This can be prevented by setting a root password. Ubuntu has a passwordless root account, but the account is disabled, and it's this mechanism that allows for passwordless root in recovery mode. Setting a password on the root account ( sudo passwd root from an admin account) fixes this.

modify the boot menu : You could also choose to remove the recovery mode from the boot menu or lock all menu items accept the default (so a password will be required to choose anything but the default entry), and/or perhaps set the time-out to 0 seconds. This prevents any user to boot anything else than the default system.

When locking the boot menu like this, be aware that you can't get to maintenance mode either - not even after a regular GUI login (see further). So you're options are

  1. never troubleshoot; only re-install
  2. boot from a rescue cd, after unlocking the BIOS to allow booting from a CD
  3. provide ssh access so you can get a remote console, either for toubleshooting or for changing the boot menu back to something that will allow you a maintenance console

GRUB passwords, timeouts and menu-items can be set in /boot/grub/menu.lst (sometimes /boot/grub/grub.conf), and are documented there. Encrypted passwords can be generated with grub-md5-crypt or inside de grub shell.

In case you wonder why this is necessary : what would you do when you forgot your root password ? Why would that be different for someone who never knew that password to begin with ?

Setting a runlevel 1 password is done in /etc/initab, by adding 'su:S:wait:/sbin/sulogin /dev/console' following the line 'si::wait:/etc/rc.d/rc.sysinit' - should you need it : Ubuntu apparently takes care of this when you reset the root password.

manage your users

Ubuntu disables the 'root' user and uses 'sudo' for all system administration tasks. During Ubuntu setup, you create 1 user that will have the right to sudo and be able to administer the system. Using sudo also allows for fine-grained control over which user will be allowed to run what command.
So, create one or more "admin" users, and use sudo to gain administrator privileges.

su and sudo

don't log in as root; log in with a user account and su, or stick with Ubuntu's sudo-policy. Nonetheless, set a password for root so you can get in maintenance mood if you ever need to, while still having maintenance mode protected from unauthorized users.

no shell for users with restricted rights

create a user account without a login shell (e.g. set the login shell to /bin/true). This prevents the user from logging in on a console and run commands from there.

This needs testing : some things might not work without shell. An alternative is to set up the user with a restricted shell.

force GUI logins

After setting up Gnome or another Desktop environment, the system will start in GUI mode. (if not, set the default runlevel so that it does). Using a desktop manager such as gdm, you can further set up AutoLogin

Forcing the user into a graphical desktop environment helps to prevent the execution of arbitrary commands (no console, no terminal, ...), and is especially useful if you've set up a locked down desktop environment (eg KDE Kiosk mode, ... ) : you don't want the user to circumvent your configuration by simply leaving the locked down desktop.

Don't let users drop out of the GUI. Use a login manager such as gdm, kdm or xdm. With those, when a user logs out, gdm will offer a GUI login again, and possibly log in the kioskuser again automatically, so that there is no way to drop to a console. Prevent access to a terminal emulator (xterm, ...). Your goal is to prevent the user from running any command other than the applications from the menus. Without shell or console access, the user might be able to create a script and make it executable, but there's nothing to run it. The user can create "Launchers" on the desktop, but has insufficient access to programs to execute anything.

Check wheter a knowladgeable user could find alternative was to run a shell or other programs : The user might be able to create a script and make it executable. The user might be able to create "Launchers" on the desktop, and try to make them launch an arbitrary program, a shell, or a script interpreter. Can the user run xterm or an other terminal emulator ? Shell out from a text editor or run an "exec" from some other program ?

Consider filesystem permissions

It makes sense to have a closer look at user (group, world) permissions on the system. The following command lists files that are "world writable" - i.e. any user can change them. If you find any, you may ask yourseld if that is actually a good idea.

 	find /bin /etc /lib /opt /root /srv /var /boot /sbin /usr /sys  -type f -perm -0002 -exec ls -l {} \;

	

Likewise, this commands lists files that are "world readable" - any user can read them :

	 find /bin /etc /lib /opt /root /srv /var /boot /sbin /usr /sys  -type f -perm -0001 -exec ls -l {} \;
	

You'd be surprised ...

This is a nice expose on < href="http://www.linuxsecurity.com/content/view/119415/49/">file permissions and ownership on Linux, worth a read if you install nautilus to let your kioskuser browse the filesystem.

consider "Bastille"

Bastille is a program that will walk you through a large number of configuration settings to help you harden the system, i.e. change the default general purpose configuration into a configuration specific to the role you've assigned to the computer, in this case a kiosk system.

To install and setup bastille for the first time :

	
	sudo apt-get install bastille
	sudo bastille -c
	

Of course you will have to consider exactly how you want to harden your kiosk in order to make the right choices : Bastille is just a handy tool to help you implement these choices (and a very usefull checklist). Here are some usefull settings and considerations for a Bastille Linux Kiosk. You do need to test if everything still works as expected after you've applied them.

you can undo the changes by running RevertBastille or bastille -r

Deep Freeze

DeepFreeze is a commercial product to restore a computer's configuration to a predefined state, i.e. you configure a system, 'deep freeze' it, and then at every system startup, that state is restored no matter what happened during the previous session. It's a Windows thing, but a guy named lukeprog found a way to mimic DeepFreeze on Linux.

Basically, what we do is backup a preconfigured /home/$USER directory to a tarbal (preserving file permissions !), then restore it so all previous changes (including changes to the user-specific hidden config files) get undone by the clean original.

Linux DeepFreeze emulation


Koen Noens
July 2006

ubuntu logo gnome footprint logo linux tux Secured - Bastille Hardening Linux Questions