DesktopTeam/Specs/Intrepid/GuestAccount

GuestAccount

Revision 2 as of 2008-06-12 12:31:52

Launchpad Entry: gdm-guest-login
Created: 2008-06-09
Contributors: Sebastien Bacher, Matt Zimmerman, Martin Pitt
Packages affected: gdm, some new binaries in a "guest" 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. An existing user must authenticate the start of a guest session, so that it cannot be abused without the owner's knowledge.

Release Note

TODO when spec is nearing beta.

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.

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
guest-account; the postinst creates a PAM user 'sys_guest' with a system UID (< 500).
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.

Implementation

TODO: figure out a place where we can hook in code that runs as root, when gdmflexiserver triggers a new session. This needs to mount a tmpfs and umount it again when the session ends. Options:
- PAM module, use pam_listfile on a file with sys_guest in it. Per-user AppArmor restriction does not work with only a PAM module, though.
- gdm 2.22.0 has the beginnings of guest account support. However, the plans for this are unclear at the moment. Martin Pitt started a discussion on the upstream ML.
- Wrap startup of X server, ConsoleKit registration, and gnome-session into a new binary, which also sets up home directory. This can be covered by AppArmor rules, and be a dbus system service. Access to starting it is (by default) restricted to current foreground sessions with a PolicyKit privilege. This reinvents part of the things that gdm does for us, but avoids putting special cases into gdm, and works nicely for kdm as well.

Test/Demo Plan