Chromium OS Report Part 2

User Accounts and Management

The Chromium OS device includes many configurations such as network, whitelist, bookmark, themes, and etc. We can simply distinguish these settings between system settings and user preference. In general, every user would like to have own configuration. This means user can define their theme, network configuration, and etc. But user’s data is always stored in the cloud server in the cloud-based device so that we have to sync these data down to device from web. For this reason, the Chromium OS device should know that which user is logging in to device, and then sync his data down to. Therefore, Google’s Chromium OS team develops some mechanism to manage user accounts and settings.

1. Design Philosophy

Figure 1 Design PhilosophyFigure 1 shows that the design philosophy of user accounts and management.

1.1 User account is used to store:a. System Settingsb. User Preference

1.2 Storing user’s data in the cloudUser’s data should be stored in the cloud (remote cloud server). That means we can obtain our data anywhere that has network supported.

1.3 We want to support OpenIDThe OpenID is a shared accounts that user can only use an account to access all sites which have supported OpenID.

1.4 Devices are easy to share among usersBecause all data are stored in the cloud, user can obtain his settings, user data, and preference in any Chromium OS device.

1.5 High level securityYou don’t worry about your device is stolen, because your data are in the cloud, not in the device.

1.6 Manage a list of users who are allowed to log inWhen you in a group and to share a Chromium OS device, you can define who can use your Chromium OS device.

1.7 Owner can optionally enable an incognito modeIf you want to share your device to other users, you can set this device with incognito mode. This helps you to manage your device, because this mode doesn’t sync data down and doesn’t persist data when the user logs out.

2. ObjectiveFor the first version, Google’s Chromium OS team wants asserting these

about logging in to the device:1. We want the device to be as shareable as a Google Doc.2. Require connectivity for the initial authentication.3. We believe users want to control who can log in to their machine.4. The traditional user account management to be onerous.

In the system settings and user preference issues, we can focus on several requirements:1. We must come up with a sane way to overlay user preferences on system

settings.2. A mechanism to allow which user can log in to device, including allowing

anyone to log in to the device.3. Don’t want to support single, shared account. (Multi-user based)

3. Design HighlightsIn the cloud-based device, ideally, we would like all of the user cloud data

can be cached locally, so that their computing environment can follow them seamlessly from device to device. Following is a case which says in Chromium OS site:

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.

We can observe that when user goes through different countries that have difference keyboard layout, in generally, device should shows a correct layout for user.

But in the some critical conditions, we can get the user preference correctly. For this reason, we divide settings into system settings and user preference. When the device tries to apply the user’s preference fails, the Chromium OS device will fall back to the “none” setting which is defined as “system settings”. The system settings include basically Wifi networks setting, this causes user can use the device to do basic authentication.

The Table 1 shows the detail of system settings and user preferences. You can reference it to define your own setting items.

System Settings User PreferencesLocaleWifi networks

Described in this doc:OwnerWhitelistPromiscuity

BookmarksNew Tab pagePreferences (browser settings)Address bar profileThemesPinned tabsNotificationsPrinters listWiFi network listMost recently used SSIDFav iconsThumbnails

Autofill (passwords, form data, etc.) Extensions 

Table 1 Detail of System Settings and User PreferencesIn the Wifi network setting, we need a user to have done the configuration first. This is because we have to initially configure the owner’s account. Following are some requirements for settings:

1. System Settings need to be accessible to all authentication users2. The data only can be accessed by their owner. 3. Client side sync engine should be able to distinguish system settings from

user preferences.

Figure 2 The Requirements for Settings

4. Caching and Applying Config InfoWe have to design a system to sync the settings and preferences from cloud,

and then apply them on appropriate time. Here are some characteristics we need to notice:1. User preference will be synced down and cached in the user’s data partition.

These data should be encrypted by default.2. System settings should be usable during boot process. 3. System settings should be writable only by the owner. 4. Multiple sources of config data need to be sensibly overlaid on one another.

Figure 3 Shows the procedure that how to sync user preference down in to device.

AccessibleSync Engine

Figure 3 Procedure of The Synced User Preference Down in to Device

5. Keeping Track of the Owner and the WhitelistBecause the root can do much things that can demand your device, we must

develop other mechanisms to against root seems. Google’s Chromium OS team has developed the “ownership” and “whitelist” mechanisms to solve this problem.

These data are stored in files with appropriate format, such as SQL database, text file, and etc. The first important thing is these data should be encrypted at shutdown with a key that’s wrapped to the TPM. Therefore, these data can only be read when the device is on. When we turn on the device, we have to decrypt the data as early as possible in the boot process, so that we can bring up networking.1. Promiscuous Mode

If the owner has opted out the whitelisting, we allow every user with valid Google Account to log in, but they all get a tmpfs home directory.

2. Incognito ModeA stateless session that require no login and that caches data only until the session is over. There are no state will be synced down from cloud and no state from this session would persist past termination.

By default, a Chromium OS device will be opted in to whitelisting and opted-out of Incognito mode, continuing our theme of being secure-by-default.

Figure 4 The Procedure of Syncing Owner and Whitelist Data DownFigure 4 shows the procedure of syncing owner and whitelist data down in to

device. The data should be encrypted when the system shutdown. When the system is booting, these data will be decrypted as early as boot process. This procedure can make much securities for our system, because these data only can read when the device on. In addition, these data do not accessible immediately when the device off, because the data have been encrypted.

6. Managing Write Access to System SettingsWe don’t want the random users able to add to the whitelist, set the device

to promiscuous mode, or reset the default network. Design a mechanism to against root is not a worth thing.

The attacker could just work around our security measure. So we create a daemon, settingsd, for user. This daemon manages the write access to the system settings, and possibly also handles exporting settings in a form appropriate for other services.

At each boot, we will generate a random nonce. The login process will check if the user logging in is the owner. If so, it hashes the nonce with the user’s password, passes it to settingsd, and passes the nonce into the user’s logged-in session. When the user changes the system settings, the system prompts for the password, hashes the nonce with it, and use it as a key to HMAC the settings changes.

Figure 5 Access Right of Random UserFigure 5 shows the access right of random user. Any user who is not in the

whitelist cannot change these settings.