Launchpad Entry:gdm-guest-login
Created: 2008-06-09
Contributors: Sebastien Bacher, Matt Zimmerman, Martin Pitt
Packages affected: gdm, some new binaries in a new gdm-guest-session package
Summary
It is very common to lend someone else a laptop for a quick email check, or having one's computer play music and be a surf station on a party.
We propose to set up an easily accessible guest account by default, which will have limited system access and no permanent hard disk storage. (Documents and Data are deleted on reboot): An existing user must authenticate the start of a guest session, so that it cannot be abused without the owner's knowledge.
Release Note
The user switching applet now provides an extra entry for starting a guest session. This creates a temporary passwordless user account with restricted privileges; it cannot access any regular user's home directory, or permanently store data. This is sufficiently safe to lend your laptop to someone else for a quick email check, or using it as a surf station for guests in your house.
Rationale
Common practice for many people is to create a "guest" user account with a trivial or empty or empty password, but this is a potential security threat.
A locked down guest session which is provided by default is both more secure and more accessible and convenient.
Use Cases
- Mark is on a Ubuntu conference and discusses some stuff with Vincent. In order to answer a question, Vincent needs to check something in an email he got recently. Mark clicks on "start guest session", and 15 seconds later Vincent has a fully working GNOME desktop and can read is email, do ssh, etc. without interfering with Mark's programs and data, or being able to steal Mark's secret world domination plans.
- Daniel invites his friends to his monthly DJ jam in his house. Since his fellow hackers can't survive without an occasional look into their email or google, he just leaves the guest session running, so that people can surf and use their USB sticks.
- Jayne is at home/the office/Anne's house working with her notebook. Someone marvels at her Ubuntu Desktop - "Hey, what's that?". "Ubuntu Linux", Jayne says. "Wanna try it"? She switches to the guest account and lets someone have a hands-on look at what an advanced computer system can do.
Requirements
- Must be fast, so that it isn't too uncomfortable to use.
- Should completely lock down file system access to all unnecessary parts, most importantly other user's home directories.
- Must not accumulate cruft; only use a temporary home directory. Users can use USB sticks for carrying away downloaded data. They must not be able to access already mounted USB drives from other users (this is already true and implemented for permanent users, though).
- This design shouldn't aim for ultimate security. In the use cases, the guest users are somewhat trusted and also observed while they work on the box. We do not design a solution that can resist half an hour of unobserved tampering. In particular, this is not strong enough to be a fully secure kiosk solution (which is why we require authentication from an existing user).
- Block access to cron and at.
- Suppress guest logins on the live system.
Design
- Add a new option "Guest session" to the fast-user-switch-applet list.
- Put the infrastructure of the guest account into a new package
gdm-guest-session; it cares about setting/cleaning up the guest PAM system user.
- Use a tmpfs as home directory.
Use AppArmor rules to completely hide /home, and give read-only access to /boot, /etc, /lib*, /opt, /root, /sbin, /srv, /usr, /var.
- Lock down network access to only TCP and UDP.
Implementation
Session setup
Ideally the new guest session infrastructure would use a script to wrap startup of X server, ConsoleKit registration, and gnome-session into a new binary, so that it becomes independent of old/new gdm, kdm, etc. However, this turned out to be too brittle due to countless bugs and race conditions in X drivers and the kernel, which gdm/kdm all managed to work around.
Thus we will extend gdm to allow spawning a new X server for the special :guest user (which is not a valid PAM user name and thus cannot collide with any real user). This will not ask for a password, but instead run the guest session setup scripts and start the new session immediately. Since the FLEXI_XNEST_USER and FLEXI_XSERVER_USER gdm commands only work for users which are already authenticated against gdm, this fulfills the authentication requirements from above.
In :guest mode, gdm will not run the standard /etc/gdm/Xsession script, but a wrapper shipped by gdm-guest-session which just execs the original gdm Xsession script. This wrapper script can then be covered by AppArmor rules.
UI changes
f-u-s-a will get a new entry "Start guest session"; possibly we will do the same for the logout dialog (note that we will not use the already crowded Ubuntu dialog, but the split upstream one). Both will just lock the screen and call a script from gdm-guest-session to start the guest session.
Test/Demo Plan
- Start a regular user session and verify that "Guest session" appears in the user switching applet (not in the live system).
- Click on it, this should spawn a guest session. In it, verify that you can use nautilus, Firefox to browse the web, but trying to access
anything in /home fails. Also check that you cannot use atq and crontab.
- The guest session's user switching applet should not have "Guest session". Click on your regular user name. This switches back to the normal user's session, whose screen should be locked.
- Click on "guest session" again in the applet. This should bring you right back into the existing guest session, which shouldn't be locked (no password!)
- Exit the guest session. Verify that there is no remaining
/tmp/guest-home.* any more.
Outstanding Issues
- gdm 2.22.0 has the beginnings of guest account support. However,
- the plans for this are unclear at the moment, upstream
[http://mail.gnome.org/archives/gdm-list/2008-June/msg00008.html does not respond] (neither on IRC, or private mail), and it is not very likely that we will get the new gdm for intrepid for various other reasons, we will not rely on that for the initial Intrepid implementation.
- Idea: On logout, offer the option to turn it into a permanent account
- Provide login directly from gdm (not just through f-u-s-a), with an "authenticate as this user" UI.
- Unfortunately we cannot reliably restrict network access for the
guest user very much. The iptables owner module does not work any more and AppArmor only provides very coarse network access control.
- "An existing user must authenticate the start of a guest session" should be optional, so that someone can use the computer without anyone else being present.