Abstract

End users must already have, or be willing to create, an account that is used to store preferences and settings. Along with Google Accounts, we want to support other authentication systems, particularly OpenID.

Storing preferences and settings with the account in the cloud allows end users to maintain a consistent user experience while switching among Chromium OS devices.

Chromium OS devices are designed to be easily shared among users, while still providing a high level of security for the owner of the device and other authorized users.

Owners of Chromium OS devices can choose to manage a list of users who are allowed to log in to a device, providing a higher level of security for the device.

Chromium OS also provides a Guest mode, allowing anyone to browse with the device without preserving any data, preferences, or other information after the session ends. The owner of the device can choose to disable this mode.

Objective

For V1, at least, we are asserting the following about logging in to Chromium OS devices:

We want the device to be as shareable as a Google Doc.

The first time a given user logs into the device, we require connectivity for the initial authentication.

We believe users want to control who can log in to their machine.

We consider traditional user account management to be onerous.

Our goal is to enable use cases like the following:

I have a Chromium OS device that I use and have configured
to work on my home WiFi network, which has some Network Attached Storage (a NAS). A friend asks if she
can borrow my device to do some work. I log out and hand her the
device. She logs in. The device should remain associated with my WiFi
network, though her preferences (address bar state, installed apps,
privacy settings, etc) should sync down and be applied for her
account. As a byproduct, my friend has
access to my NAS. That's okay.

without also enabling attacks like this:

I
have a Chromium OS device that I use and have configured
to work on my home WiFi network, which has a NAS. Someone steals my device. The thief has a Google Account. He logs in, and not only does
he have a local account on my machine, which removes a significant
obstacle to compromise, but he also has access
to my NAS and everything else on my home network.

At a high level, what we're saying is that, for certain settings, the right thing to do is have a per-device system setting override a user preference—but that some per-device settings could be sensitive. This insight dictates several requirements:

For users who log in to the system, we must come up with a sane way to overlay user preferences on system settings.

There
must be some mechanism to allow users to manage who can log in to the
device, including allowing anyone (who has a Google Account) to log in to
the device.

We must not drive users toward having a single, shared account; common multi-user use cases should fit well within our design.

It's worth noting that we also have some thoughts about supporting users without a Google Account; see the Login document, and the discussion of "Guest" mode later in this document.

Design highlights

We've shown above that we must, at least, deal with the wrinkle where
we need to access some available, but secured, wireless network to log
a new user in. After that, ideally, we would like to apply all of a
user's cloud-cached preferences locally so that their computing
environment can follow them seamlessly from device to device. In
addition to the issue of wireless networks, consider also the case of
keyboard layouts:

Antoine is French and has set up his Chromium OS
device with a US keyboard to have some key mappings that will handle accents
nicely for him. When he goes to France and logs into his sister's
Chromium OS device with a French keyboard, it doesn't make sense for his
mapping from home to apply. In fact, it should fail, as the machine
has a different keyboard. When I log in to Antoine's machine, though,
my default US keyboard mapping can be applied, and should be.

The specifics of trying to apply a given user preference and having it
fail vary depending on the preference in question. We define system
settings as any setting we need to be able to apply before a user has logged in.

Currently, we break down system settings and user preferences as follows:

For
at least the "current WiFi" setting, we need a user to have done the
configuration first. In other cases, we will have sensible defaults
that we will use to initially configure the owner's account.

These features dictate several requirements:

Settings
deemed system settings need to be accessible to all authenticated
users, but not to just anyone who pulls the hard drive.

User preferences should be stored so that only the user in question can access them.

The
client side of the sync engine needs to be able to distinguish system
settings from user preferences, so that it can store them separately.

Syncing mechanism

Out
of scope for this document. All that matters from our point of view is
that the client side can distinguish between system settings and user
preferences.

Caching and applying config info

The Linux
system services that rely on these settings and preferences access them
in a variety of ways, though mostly through configuration files. We
must design a system that can use the preferences and settings we sync
down from the cloud and apply them at the appropriate time. This is
to-be-designed, but must have the following characteristics:

User preferences will be synced down by a Chromium-based browser and cached in the user's data
partition, which is encrypted by default. The system should be capable
of applying these as the user's session is being brought up.

System settings must be usable during the boot process; otherwise, we won't be
able to connect to a network for online login. We would like, however,
to at least protect these settings while the device is off.

The system settings should be writable only by the Owner; we can't
cryptographically enforce this, but we can at least use some system
daemon to enforce it.

We need to enable configuration to be
federated; multiple sources of config data (settings and prefs) need to
be sensibly overlaid on one another. The precise semantics depend on
the setting in question.

Keeping track of the Owner and the whitelist

The
point of keeping track of who the Owner is and who's on the whitelist is to keep
the attacker from getting an account on the device. If they've already
managed to root the box, or to exercise a kernel vuln, they can work
around Ownership and whitelisting anyway (replace the session manager or the chrome binary, or something else). So, designing a
mechanism that is robust against root seems ... futile (we're working
hard to take root away from all userland processes regardless, in our
system hardening efforts).

If
the owner has opted out of whitelisting, we allow every user with a
valid Google Account to log in.

Guest mode

We are considering logically extending the notion of "Incognito"
mode found in Chromium-based browsers to Chromium OS-based devices: a stateless session that requires no login and that
caches data only until the session is over. No state would sync down from the cloud, and no
state from this session would persist past termination. The option to start such a session will be on by default, though the Owner can disable it when she is logged in. We create a
tmpfs on which to store the Chromium browser's session data, and open up an instance
of the browser in incognito mode for the user. Once that instance
is exited, the session is over and we return to the login screen.

By default, a Chromium OS device will be opted out of whitelisting and opted-in to Guest mode. We will provide UI that allows a logged-in Owner to explicitly add users, and provide the Owner an option at that time to opt-in to whitelisting and Guest mode.

Managing write access to system settings

Only
the Owner should be able to change system settings. We don't want
random users able to add to the whitelist or enable guest mode inadvertently. As a root/kernel exploit
means the game is over anyway, it's not worth trying to design anything
that is robust against that kind of compromise; the attacker could just
work around our security measures. So, we will have a settings daemon,
settingsd, that manages write access to the system settings.

When the first user logs in, we generate an RSA keypair and store the private half in his encrypted home directory, exporting the public half via settingsd. All requests to update the signed settings store (which includes the whitelist) must contain a valid signature generated with the owner's private key. When settingsd receives a request for the value of a system setting, it returns the signature over that value along with the requested data. The requesting process then verifies this signature, ensuring that only values which are correctly signed by the Owner are respected. Of course, a root-level exploit could replace the exported Owner public key. As stated above, though, the game is already over in this case.