Gnome lockdown - definitions and requirements

[Alexander Larsson <alexl redhat com>]

Gnome lockdown
--------------

Its generally agreed that Gnome needs to support "lockdown". However
nobody really knows exactly what this means, or exactly how you would
add support for it. I've spent some time looking at various uses and
implementations of lockdown, and have come up with this proposal of
the requirements and definition of focus for the Gnome version of
desktop lockdown.

Background
----------

It seems that there are three major cases that people want lockdown
functionality for. These different modes of lockdown each have
different requirements and uses. We need to make sure our lockdown
framework can handle all of these cases:

1. Kiosk

These systems are put in public spots, and are meant to be used for a
very limited task. Common examples are web browsers limited to the
internet bank in a bank office, a book searching application in a
library, lightweight client for logging in to a windows server using
rdesktop etc. Basically no UI other than a specific app is available,
and no data is meant to be stored locally on the machine. 

2. Public Terminal

These are more like ordinary desktop computers, but they are not
personal like normal workstations. You don't have to log in, and no
personal files, settings, etc are available. Each machine look
similar, and you need lockdown of the UI to make sure that one user
cannot mess up the machine so people after him can't use it. A typical
real-life example is a room of public computers in a school or a
library, where users can read their email, write documents, print,
save on a floppy, browse the web, etc. These could also be found as
public terminals in an office.

3. Limited Workstation

These are your typical personal workstations, as used in an
office. However, to limit support issues and sometimes to make the 
user interface easier to understand or use less resources, the system
administrator has used lockdown to limit configurability and remove
"complicated" features from the desktop. Typical example could be
computers for use in a call center, personal workstations in a non-IT
company, or workstations for student at a university. 

Requirements
------------

Lets explore the properties and requirements of these types of lockdown:

1. Kiosk

Typically you want to disable most of the desktop, including panel and
file manager. Perhaps in some cases you still want a panel, but
totally locked down and with most operations disabled. 

There is no need for login/logout, and the system logs in the default
user automatically without password. If you somehow manage to kill the
session it should log in again automatically. 

You need to be able to specify what apps to run on login, and you
should be able to monitor and restart apps if they die. Other common
requirements are:
* command line switch for fullscreen mode on startup for the apps you
run in the kiosk
* Make sure you can't start any apps except the kiosk apps
* limit browsability in web browser to some specified servers
* remove saving and other features in browser
* allow you to specify some windows as not having decorations (since
they are not needed if you have only one app on screen)

These machines are created only for the purpose of being kiosks, and
as such there are great possibilities to specialize the machine, by
e.g. removing everything you don't need and setting very strict fs
permissions.

2. Public Terminal

Similar to Kiosks, these machines are typically set up to use one
specific user and use automatically log in, or log in with an empty
password. We might also want automatic logout on idle, as sometimes
you want to do cleanups between login sessions and this is a good way
to force prople to log out. To avoid people locking the screen with a
password the screen locking feature needs to be disabled.  

These systems are often installed in a network, so its important that
the same user is able to log in concurrently on several boxes without
affecting each other.

You want to disable all types of functionality with a history, or at
least be able to clean it out (although doing so probably requires you
to log out between users). This is to avoid seeing the previous
persons cookies, recently edited filenames, browser history, saved
passwords etc.

You want to disable changing of most settings, make sure some
important links stay on the desktop, and that the menus and panel
can't be changed or removed. You might also want to limit the apps
that are available to the user, hide the command line and hide most of
the filesystem.

Also, you probably want some of the other features listed for limited
workstations below.

3. Limited Workstations

These are typically personal desktops, or at least shared machines
where you log in with your own user, and a lot of personal data and
settings are tied to the user. On systems like these there are often
several categories of users with different forms of lockdown and
default settings.

To handle categories we need some easy way to add users to groups,
such that some specific defaults and lockdown properties are used for
persons in that group. At the minimum we need a "major" group setting,
which specifies all the base settings to use, but it would also be
nice if you could add additional subgroups that i.e. add extra stuff
to menus or give the user extra privileges. Consider for instance a
student setup where the student group gets the defaults set up, but
you also have groups for specific classes that add class-specific apps
to the menus, allow you to use the CD burner or give higher printing
quotas.

Workstations are normally set up so that they are a bit less locked
down than Public Terminals (although not always), but instead (or
rather because of that) they typically require a much broader spectrum
of lockdown settings. 

The most basic part of limiting workstations is to set up the default
configuration for a group, including panel layout and things like
initial desktop contents. These settings are then locked down to
various degrees so that the user can't change them. Using lockdown
features such as:
* Lock down panel layout
* Lock down panel content fully or partially
* Disable menu editing
* Make specific launchers on the desktop and panel immutable

To make the UI less daunting for some user you want to be able to do
things like:
* Hide parts of the filesystem
* Hide access to the terminal
* Hide root-only settings

There are also all sorts of other features that people might want:
* Disk quota
* Printer quota
* Disable access to specific hardware (e.g. CD burners)
* Limit network server browsing/connecting
* Disable changing of desktop background and other purely visual prefs
* Don't allow user to change printer

And doubtless dozens of other things.

Implementation
--------------

To implement all of this we have various bits of technology that we
can use. As the base we have the unix user and group system,
filesystem permissions and other permissions. To get per-user settings
and data we have NFS and other network filesystems we can use for the
home directory. Then we have gconf, which supports both mandatory
settings, system defaults and lets us change the ui depending on key
writablility. We can also add keys to gconf to add ways to disable
certain desktop functionality or user interface items. There are also
various system configuration files that let us do things like disable
ctrl-alt-backspace and other things needed to lock down a box. We can
also use scripting to allow you to specify things that need to happen
at startup/shutdown/login/logout.

I think the basic idea should be to use unix permissions and system
settings for enforced lockdown, so that a user can't really do
anything with the system, even if he's a really clever hacker
exploiting some bug to get a terminal. Then we use gconf to limit the
user interface so that "normal" people can't do anything bad and so
the interface isn't full of operations that result in "permission
denied" dialogs. 

For public terminals we need to make sure we can handle one user
logging in multiple times without affecting the other sessions. I
think we handle this pretty well currently with a local or per-machine
homedir.

For limiting workstation using groups we should probably extend use of
the unix group system, since that means we can continue to use groups
for file permissions in addition to general UI lockdown. This needs
some work in gconf to make it be able to use group membership to select
gconf sources.

Running scripts on login/logout should be easy to do by adding stuff
to the session scripts.

Most of the limitations in configurability we can do by using
mandatory settings in gconf. Then we can add gconf keys for specific
features we need to be able to specify. I think most of these should
be in terms of overall desktop policies, but we also probably need
some that are very app specific.

Machines for the different modes would typically be set up something
like this:

Kiosk: kiosk-specific os installation with limited amount of programs
available and very tight permissions. Local, mostly read-only
homedir. gdm set to autologin a specific user. Re-initialize homedir
from read-only source on login. Use session to specify apps to run and
keep running.

Public Terminal: typical distro installation, gdm autologins a
specific user, Local or per-machine homedir. mandatory gconf settings
stored read-only on local disk or on NFS.

Limited Workstation: typical distro installation. log in using
user+password. authentication via network (NIS, ldap, whatever).
typically networked homedir, but in rare cases local homedir, but then
each user can only use his personal machine. mandatory and default
gconf settings are stored on NFS or pushed to local disk
automatically, or some sort of LDAP backend for gconf is used.

One problematic area is laptops. Since these are not typically
networked all the time, some things related to lockdown get a bit
complicated. They are somewhat of a mix between public terminals and
limited workstations since you can't use things like network
authentication and networked gconf, at least when not connected to the
office network. This gets especially tricky if you want to use
e.g. your NFS homedir when the laptop is plugged into the network but
still be able to use your laptop without the network...

Work to be done
---------------

It seems that most of the building blocks for the lockdown framework
is already available in a normal unix Gnome system. Some GConf work is
needed to make it use different sources depending on what groups the
user is in, and an LDAP based backend (or other network config
storage) would be nice.

We need to work a lot on handling non-writable keys everywhere in
the user interface, and we need to make sure you can easily configure
things like initial panel layout and panel menu content using
gconf. We also need to add new gconf keys as needed to disable things
needed for the various lockdown modes.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a leather-clad crooked ex-con haunted by an iconic dead American 
confidante She's a beautiful communist bodyguard who don't take no shit from 
nobody. They fight crime!