This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
ABSTRACT - Chrome operating system is designed by Google for users who spent most of its time on the internet. The operating system is based on Linux kernel and runs on both x86 and ARM processors. The operating system is designed to be simple, fast and secure. Chrome OS has a few variants for its user interfaces but all follows a unified tab concept. Each of these variants is catered for different group of users and systems. Chrome OS firmware is modified from traditional firmware to provide a faster and more secure boot. The firmware was strip of all unwanted steps and have added feature such as recovery and verification. To Chrome OS, threats come mainly from 2 sources, remote and theft of device. Therefore security mechanisms are designed to tackle these threats. This paper will cover Chrome OS user interface, software architecture, source code management, firmware, platform and security features.
Index Terms - Operating System, Design, Architecture
Google Chromium Operating system (Chrome OS) is an open-source, lightweight operating system designed by Google to work with web applications. It powers systems ranging from small-sized netbooks to full-sized desktop system. Chrome OS is based on Linux kernel and its main platform is the web. 
Chrome OS has three key aspects. They are speed, simplicity and security. In order to achieve speed, it is designed to be fast and lightweight thus allowing system to start up and get onto the web in a relatively short amount of time (in the range of seconds!). To achieve simplicity, its user interface follows a minimalist approach that much resemble chrome web browser. As for security, designers of Chrome OS went back to the drawing board and completely redesign the underlying security architecture to prevent hassle from virus and malware. 
Chrome OS run only both x86 and ARM processors. The main platform for developers will be the web. Regardless of which web technologies are used to develop the applications, it will work automatically on Chrome OS. 
Chrome OS and Android are not connected to each other. Android is designed for smartphones to set-top-boxes to netbooks while Chrome OS is designed for users who spent most of their time on the web. It is used to power systems ranging from small netbooks to full-sized desktop. However, there are some areas which they overlap. 
The objective of this paper is to describe various designs and architecture of Chrome OS. It will cover the tentative concept and design user interface, software architecture overview, source code management, firmware design, platform design and security features.
The rest of the paper is organized as follows: Section 2 covers terminologies used on this paper. Section 3 covers user interface designs and concept. Section 4 covers software architecture overview. Section 5 covers source code management, Section 6 and 7 describes firmware platform designs respectively while section 8 and 9 covers security features and conclusion.
This section will cover the various terms used in this paper.
OS - Operating System
Chrome OS - Google Chrome operating System.
Tab strips - it is like the task bar of Windows OS. It is used to manage applications and web pages in Chorme OS.
Pixel-level window positioning - the window can be positioned at any location in the display.
Panels - a container or floating window that handles secondary tasks.
HTML5 - the latest propose standard for HTML.
Pinned tabs - tabs that are locked at the left side of the tab strips.
Chromium - Chromium web browser.
User-land - application space external to kernel space and is protected by privilege separation.
Upstart - An event-based replacement for the /init daemon of Linux kernel which manages tasks and services.
Cloud - Metaphor for internet.
OAuth - An open protocol that allows secure API authorization between desktop and web applications.
Dm_crypt - A virtual encrypting block device.
User interface concept follows minimalist approach of using as little space as possible. This is achievable through the use of tab strips. In the current design, Chorme OS will run in full screen mode without any pixel-level window positioning feature. Users can access different windows via shortcut keys or overview mode.
All applications on Chrome OS are classified under primary and secondary tasks. Primary task are applications such as web browser and spread sheets while secondary tasks are applications such as chats and music player. Chorme OS uses tabs on the tab strip to handle primary task while panels are used to handle secondary task. These panels are initially located at the bottom of the screen but can be shifted to either sides of the screen and appear much like side bars of Windows Vista.
Similar to Chrome browser, the OS uses HTML5's offline modes, background processing, notification and other features to enhance its functionality. To aids quick access to applications, pinned tabs and searches are used. Pinned tabs remain available across sections. Any external link open from these tab will be opened outside this group. To further ease the access to applications, a primary access points is included for quick access to frequently used application and tools.
USER INTERFACE VARIANTS
Chrome OS has 4 structures. Each of these structures is based on the unified tab strip concept. The structures are Classic, Compact, Sidetab and touchscreen. Each of the structures differs in which their address bar is placed. An address bar in Chrome OS contain navigation control, menu and search box.
This is the basic structure which contains only a maximized Chrome window. It appears much like Chromium in maximized mode hence users who is familiar with Chromium can easily adapt to Chrome OS. In this structure, address bar is linked to the tab and therefore making it less logical to use it for tabs swapping and launching of new tabs. Address bar is used to display the URL and hence making it difficult to tell where search is carrying out from as search content will overwrite the URL.
In this structure, the address bar is taken out of the tab and thus it can be use for tab switching and launching of new tabs. This design eliminates the problem faced in classic structure and it also allows applications can have full control of their content area. Content area is areas where contents of application or web pages are displayed. Since the address bar (navigation control and menu) is no longer embedded within the tab, it loses content sensitivity. Furthermore, the address bar will take up some space in the main tab strip thus leading to over crowding of the strip. Availability of current URL is also reduce as the URL is shown only during loading of site.
The address bar is taken out of the main tab strip and place at the side. In this mode, it can be used for both navigation and search. This mode allows maximum vertical display area for applications and web pages and can support larger amount of tabs. However, this mode is likely to waste spaces for users who uses little amount of tabs. This design also differs from Chromium. Therefore, users will need some time to adapt to this mode.
This design is targeted for touchscreen. The user interface is made bigger and can be hidden to show full screen content. It contains large square targets for navigation and allows quick navigation between common applications. This design however, waste vertical space and can only support short title for application and sites due to enlarged user interface.
SOFTWARE ARCHITECTURE OVERVIEW
Figure 1 shows the architecture of the OS software. The OS consist of 3 components: Firmware, system-level and user-land software and Chromium and window manager. The bottom 2 layers are the firmware layer while the middle 2 layers are for system-level and user-land software and the last 2 layers are for Chromium and window manager.
Chrome OS is built for speed and security and these aspects needs to be addressed right from the start i.e. start looking at firmware to improve speed and security.
Figure 1: Chrome OS Software Architecture
The firmware is strip of unnecessary components in order to achieve speed up booting process. Furthermore, the firmware does not support legacy hardware such as floppy drive and therefore, no time is wasted on probing for these legacy hardwares. To achieve strong security, the firmware will carry out pre-verification checks before handling over to the step of the boot process. This is to ensure that the firmware is free from attack or corruption. The firmware consists of 3 components. They are 1) verify boot, 2) system recovery and 3) fast boot.
SYSTEM-LEVEL & USER-LAND
These layers use existing Linux kernel, drivers and user-land daemons with some additions and modifications to improve performance. At kernel level, patches have been added to enhance the boot process. The user-land has been modified to execute only critical services. Upstart is also used to manage user-land services so that services are run in parallel, re-spawn jobs which crash and defer some services to achieve performance improvement.
CHROMIUM AND WINDOW MANAGER
The window manager at the second top layer handles multiple client windows in a way very similar to how other X-window manager handles. Part of Inter-Client Communication Conventions Manual (ICCC) and Extended Window Manager Hints (EWHM) specifications are used to transfer information between clients and the window manager. Chrome OS uses XComposite extension to transform and blend windows while Cutter libraries is used for animating windows and to render these windows, OpenGL and OpenGLIES are used.
SOURCE CODE MANAGEMENT
Part of Chrome OS objective is to achieve good relationship with upstream source and therefore it is structured to upstream code. Chrome OS uses Git, Rietveld and Gclient for its version control, code review and package checkout management respectively.
VERSION CONTROL SYSTEM (VCS)
The version control system of Chrome OS is Git. It was chosen because it suited Chrome OS design objective and it is the preferred distributed version control system choice for most projects which the OS uses. Hence, it provides a common ground for Chrome OS and those projects.
Chrome OS uses 3 different repositories to manage source component. They are remote or upstream repository, Google host repository and developer local repository. Figure 2 shows how codes flow between each repository. If upstream is non-Git like in bar and bash on the upstream repository (top level), a Git import tree will be created on the Google repository (bar svn import and bash .deb import). Google repository is a Git repository that is based on a specific upstream tag of the Git repository.
The process of managing repository is as follows:
Figure 2: Repository
A Git repository will be hosted on Google for currently modified source component. A new Git repository will be generated when a new package or dependency is added.
Google repository will be a clone of Git repository if the upstream source is Git.A Git repository will be created and hosted on Google repository if upstream source is not Git. It will be based on import and will re-sync to upstream automatically.
A Git repository, in the form of tarball, deb package or rpm package, will also be created for sources not hosted on VCS.
All changes will be done on a copy of the recently state release.
Rebasing is used to make future syncing easier and to separate Google bits from upstream.
The metadata chromium file is first stored in root directory. It will then be shifted to web-based database which could display Chrome OS version, upstream latest version and other information. The metadata file contains information like contain information like: package description, upstream page and repository URL, Git repository URL, URL for both Google and upstream bug database and name of license.
The commit log will contain information about source origin, commit ID, tested and upstream status. This information will provide details on the sources.
Code reviews is an examination of source code to find and fix mistakes in the early stages of development. It aims to improve software quality and developer skills. Code review in Chrome OS is done by using Rievteld. Git-cl will be used to make Git code review easier.
The firmware contains 3 major components and they are the fast boot, system recovery and verify boot. This section will cover these components.
Figure 3 will illustrate how fast the boot process is as compared to traditional OS. The splash screens on traditional OS are to notify user the state the system is at. The first hardware initialization is for the firmware while the second hardware initialization is for the kernel. The miscellaneous stuff is for kernel to start services and application it requires. The first login is to enter the operating system while the second one is to login to cloud services like gmail.
On Chorme OS system, times to boot up is greatly reduced by removing unnesscessary stuff. The followings show what has been removed or enhanced to speed up boot process.
Hardware is already known. Therefore there is no need to search for what hardware exists.
All initialization of hardware is shifted to the kernel. This allows starting of multiple devices in parallel.
Figure 3: Chrome OS Fast Boot
Splash screens are also removed as they are useless on fast boot up.
Boot loader is not necessary as Chrome OS can go to the kernel directly.
As browser is the main application, legacy software is not needed and thus they are removed.
Chrome OS is a native web device, therefore there is no need to login twice. After the login, user can access all of the cloud services.
FIRMWARE BOOT AND RECOVERY
The firmware has a recovery code path to restore Chrome OS to its original state if there is any unverified chain in the boot path or when it is initiated by user via recovery button. To aid developer who wants to run alternate software, Chorme OS has an alternate boot path. When used, it will notify the user that he is boot path not belonging to Chrome OS.
BOOT AND RECOVERY FIRMWARE FEATURES
This section covers firmware features for both the boot process and recovery.
Before any boot code can execute, initial boot stub will perform a minimum level of initialization to verify it. This prevents attacks or corruption on boot code but not the boot stub. Therefore, to prevent boot stub to be in contact with corruptions or attacks, it will be stored at non-field writable memory (eg EEPROM). On ARM, on-chip ROM will be used.
WRITABLE FIRMWARE BACKUP
Writable part of the firmware is the part which works on the reminder of the chipset and storage setup then bootstrapping the kernel off the device. 2 copies of the firmware are made with one serving as backup. This allows fallback to a last good state.
READ-ONLY RECOVERY FIRMWARE
Recovery firmware is used to recovery Chrome OS to it original state. Any corruption to recovery firmware is undesirable. Hence it is stored in the non-field writable memory (same as boot stub).
NO NETWORK ACCESS FOR RECOVERY FIRMWARE
Recovery process does not need network access by the recovering device. Thus recovery firmware only needs to recover system to a state where it can bootstrap the Linux image on local drive. Reflashing of EEPROM and reimaging can be done using that image. If network access is required, recovery procedure can use another computer, with network access, to create recovery media.
The recovery firmware do not have full network stack with WiFI configuration to support PXE boot. PXE boot introduces a number of issues which need to be resolve. Since recovery firmware is non-field upgradeable, it needs to be correct at the point of device ship out. Shipping of a mostly-working PXE solution and assume that the user have another system to backup in case of PXE recovery fail is not acceptable. Furthermore, failure in PXE recovery can only be detected by user when they use them for recovery.
If the recovery software finds a good recovery image on the recovery media, it will use that image. That image would have recovery software which will instruct the user on how to recover the system. If no good recovery image is available, it will instruct the user on how to use a second computer to create a recovery image.
Users will be able to force recovery when needed. This is done using a physical button on the device. When press, it will use the recovery firmware.
INSTALLING OWN SOFTWARE
After the kernel is load and embedded signature is checked, the initial device will be released and 3 types of kernel can be produce.
Trusted kernel. Firmware knows it signature and signing key. Normal case for production device
Developer kernel. Firmware knows signature but not the signing key. Happens when developer build and self-sign the kernel.
Corrupted kernel. Firmware does not it signature.
The user of the device will be notified when the trust chain departs from Chrome OS boot chain. It will provide a warning, a means to revert back to standard Chrome OS image and a means to allow user to proceed with the untrusted path.
This section covers various parts of the firmware.
The boot stub is located at the top of EEPROM and it contains public key for verifying the next firmware stage signature. To minimize the exposure of root key, a second key is used. This key is date-limited or numbered. This key is then used to sign firmware. TPM module can be used to validate date or key number.
A boot log, located at the bottom of writable firmware, stores events like triggering information of recovery firmware and when the recovery completes and actions taken. The log will not contain any successful boot information hence eliminates the need to have EEPROM writing support for normal boot. This also saves space needed for error logs. During autoupdate, the boot log can be uploaded.
This firmware attempts to load recovery image from external storage if there is a bad firmware or root filesystem. Most of the recovery work is done by the recovery image as it allows new or updated recovery images and instructions to be published. Since recovery firmware is not field writable, it needs to be as robust and simple as simple in order to minimize errors.
Recovery image and an installer will be downloadable. The installer will handle installation of recovery image on stored device. This installer will also be made available for all popular OS. Ideally, the installer should also allow user to backup whenever data they want to a destination drive before reformatting and writing of recovery image. The recovery image will come with a clean firmware and root filesystem. The following sections describe some characteristic of the recovery image.
USING CHROME OS
Any Chrome OS will be able to do the followings if it is not corrupted.
Run recovery installer
Download recovery image
Reformat storage device
Copy recovery image to storage device
These features will allow Chrome OS to create its own recovery device and download recovery image for another model.
READ-ONLY RECOVERY IMAGE
Making recovery images read-only is done via external storage devices. Each of the devices will have write-protect mechanism and is handled differently. SD card comes with a write-protect notch but it is implemented using software and corrupted driver can ignore the write-protect signals. Some USB drives have comes with write-protect switch. The USB drive will handle the protection. Some eMMC chips have an external LOCK pin to make it read-only and/or a write-once bit to make device read-only until reboot.
LOADING DEVELOPER MODE FIRMWARE OR SOFTWARE
If the root filesystem image is signed by someone else, a screen similar to Developer Mode screen will be displayed. It will provide a notification to the user, instruction on how to get and install a trusted recovery image and option to carry on with the untrusted recovery image.
Verifying boot is a process which ensures that all executed code comes from Chrome OS source tree. It starts from the read-only section of the firmware. Only after verification, it will then execute the next set of boot code. Verifying process is done on-the-fly to minimize delay at start up and uses stored cryptographic hashes for verification. Verification process will perform the followings:
Support field functionality upgrade.
Based on an expected state, it will detect changes in non-volatile memory.
Detect any changes in file system relevant to system boot.
BOOT LEVEL VERIFICATION
A SHA-2 hash of the read-only firmware is computed by the boot stub. Its RSA signature is then verified using a permanently stored public key. After that, the read-only firmware is used to compute hashes of the kernel and any non-volatile memory. The read-only firmware contains its own subkey and cryptographic hashes of data which is to be verified. These hashes are signed by the subkey therefore updating does not require a write-protected key. Verified boot is successfully performed upon entering the kernel.
VERIFICATION ABOVE BOOT LEVEL
Verification above boot level can be achieved by having the read-only firmware verify the entire boot partition in advance before booting process. However, it will add a huge undesirable delay to the booting process. Hence on demand verification is used.
A transparent block device is sandwiched between the runtime system and running process. It can be configured using firmware-verified initial ramdisk image or in-kernel code changes. The transparent block device will verify all blocks that pass through it with a central collection of hashes. Once the block is verified, it will be placed in page cache above the block layer. Thus verification does not occur on every read event. The block hashes will be bundled groups of block hashes. The bundled block hashes will be hashed. Hashing is then done to the subsequent list of bundled hashes. This hash is can be either hard-coded into the kernel or supplied via a device interface through trusted initial ramdisk image.
Hashes are loaded every time a read from data of each block occurs. This degrades performance. Hence instead of loading hashes for every read, a bundled of hashes will be kept in the memory after it is loaded once. The trades kernel memory for performance. However, the performance gains outweighs the memory used (estimated 1MB). Furthermore, in-memory block hashes ease linear addressing of hashes as they are in block order.
The collection of bundled hashes for the particular updating partition will be updated via the autoupdate. A utility running directly on filesystem image will generate a complete collection of hashes for a particular partition in a form of a file image. It will also generate the hash of the bundled hash. The hash will be stored in a signed or verified location and the file will be stored in the filesystem or a standalone partition.
This section will cover areas above boot level and inside OS environment. Some of these features has direct contact with end users and allows them to adjust some of its parameters.
AUTOUPDATE AND FILESYSTEM
Updates are used to add new functionality, bug fixes and enhance user performance and user interface. During an update, only part which are changed is downloaded and stored in a backup boot partition. On the next boot, the backup partition becomes a primary partition. If problem arises with an update, the system could goes back to a previous partition. On Chrome OS, the partition containing OS and other system files is set read-only. Temporary user state is stored in another partition.
CHROME OS PARITIONS
There are 4 partitions on Chorme OS. They are stateful partition which uses 1 partition, swap partition which is optional and uses 1 partition and root filesystem which uses 2 partitions.
The stateful partition is used to store state resident such as user's home directory, Chromium profiles, logs and other data. The swap partition is used as temporary RAM storage. Root filesystem is where all other filesystems get mounted on.
There are 2 root filesystems but only one of them is used at a one time. The other filesystem is used for autoupdate and backup in case anything happens and system needs to return to last good state. Currently-booted root filesystem is set to read-only and nothing can edit it. Therefore, the stateful partition is needed and is set to read-write to stored state that is required to be kept locally. Only autoupdate and applications running as root can access the other not in-use root filesystem.
The update process is still under much development and yet to have a final structure. However, some designs are already in place.
The update process relies partly on the "Successful boot" concept which will provide the state of the boot (correct, incorrect or still attempting to boot) at any given point. The other root filesystem will only be available for overwriting after a system has been booted successfully.
In order to prevent endless attempting to boot a corrupted partition, updated partition is given only a limit number of boot attempts before it revert back to previous partition. When an update is successful, a counter with the attempt value is assigned to it and it is stored in the partition table next to the bootable flag. Boot loader will check for counters of all partition and then decrease the counter (if > 0) and attempt to boot the partition until it is successfully booted or counter reaches 0. If all partition has counter value 0, the boot loader will boot from partition marked bootable.
Chrome OS device provides single sign on (SSO) capability to streamline access to cloud services. All Chrome OS devices are cloud devices. They are used to sync user's data and preference to cloud-based services. In the current design, user must log in Chrome OS device with Google account in order to know which data is to be sync to which machine.
Libcurl in Linux_PAM module will communication with existing Google account HTTP(s) API to authenticate the user and appropriate cookies will be obtained, via a named UNIX pipe, to log user to all the Google services. All this is done the instant Chromium browser starts. If authentication online is done once and network is not available later, PAM module will cache the mapping between the user and a salted hash of the password. No cookies can be acquired as there is no network and hence unexpired cookies from the previous authentication are used once network is available.
A 3 step process is used to bring cookies obtain from normal web-based login to Chromium after user session has begun. They steps are:
Get Google cookie via Google account ClientLogin
Get a one time use token to authenticate user to services.
The token is then used to exchange for full sets of browser cookies.
Since all these are done over then web, there must be some mechanism to protect the data. Therefore, the root certificate provided by a web server (that issues Google's SSL cert) is trusted by the login process. Thus is makes it more difficult to attack since the attacker has to hack Google's registrar.
Auto-login is an option which user can set in an active user session. In order to set the auto-login option, he has to manually login for that session. Upon turning on auto-login, an OAuth token is obtained and stored in the same encrypted-while-shutdown storage as system settings. This token can be revoked any time to limits risk of an attack. The login process will check for the token. In an offline login, the token alone can allow successful login.
Chrome OS allows resizing of partition without needing to erase them. This will aids system updates. Resizing is only done by the system. It will shrink the stateful partition to provide system partition with extra space. In cases where stateful partition contains too many data and it cannot provide enough space to the system partition, the system will delete some of the state information. The process will assumes the machine is left unusable during partitioning and a message will be display to notify the user.
During resizing procedure, the system may reboot and the OS will recover gracefully. The procedure assumes that the system has booted to the last partition on the disk. If not, the resizing process will only take place at next update or
Figure 4: Resizing procedure
reboot. A swap partition cannot be resized. Figure 4 illustrates the resizing procedure.
TEXT INPUT SUPPORT
Like most popular OS, Chrome OS also supports multiple languages. The support for text input on Chrome OS is built on top of the existing input text technologies on Linux. Texts can be through simple keyboard, switchable keyboard, simple IME, transliteration IME or candidate IME.
TEXT SUPPORT ARCHITECTURE
The basic architecture for the text input support is shown in the diagram. XKB (X keyboard extension) is use for languages supported by simple and switchable keyboard. A different XKB definition file will be generated for different keyboard layout.
IBus (intelligent input bus), an open source framework, is used for the languages. It will be used as input method framework (IM Framework) and serves as middle layer between applications and language-specific backend conversion engines.
Figure 5: Text input support architecture
Supporting multiple languages may pose as a security risk as indirect input layer such as IBus and conversion engines is used. Therefore, the plan is to use GrSecurity to limits resource access from IBus and conversion engines.
Text input-related data will be synchronized with the cloud. Data that will be synced are user settings, input history and user-defined dictionary. Though syncing configuration data is required, user can have the freedom to choose whether he wants to sync with other user data.
Chrome OS will provide a uniform text input experience to the user. Candidate window will be implemented as a separate process and communicates with IBus daemon via D-Bus. XKB, IBus and conversion engine configuration dialog will be part of Chrome's option dialog and they will use libcros to communicate to X server, IBus daemon and conversion engine respectively. Input language selector will be integrated as part of Chrome OS's status area. It communicates to both X-server and IBus daemon via libcros. Unlike traditional Linux, keyboard language selector will be integrated together with the input language selector.
USER ACCOUNT AND MANAGEMENT
Chrome OS devices are designed be shared among users and still provide high level of security to owns and authorized user. Owners of the device can select who is allowed to use the device. He can also enable incognito mode which allow anyone to browser the device but they will not be able to store any data, preferences, or other information at the end of the session.
On Chrome OS, there are 2 sets of settings. They are system settings and user preference. These settings are store in the cloud and retrieve while login. Chrome OS will attempt to applied the settings to the machine that the user logs in to in order to provide a uniform user experience. However, they can fail. If system settings fail to apply, the device will fall back to a sensible state and still be able to use. User preference, on the other hand, will likely to be successful. Examples of system settings are locale and Wifi networks and user preference are bookmarks and themes.
CACHING AND APPLYING SETTINGS
Chromium Browser will provide the encrypted user preference. It is then stored in user's data partition. These will be applied when the user's session becomes active. System setting, on the other hand, is made available during boot process and writable only to the owner. Multiple sources of configuration data, both settings and preferences, need to be overlaid on one another.
OWNER AND WHITELIST
Several groups of users can use a Chrome OS device. They can be owner, whitelist group or others (including attackers). A way to prevent attacks is to keep track of the owners and whitelist users. This will prevent attacker form obtaining an account on the device. The plan is to store ownership and whitelisting data in sqlite database, text file or other format. During shutdown, these data will be encrypted using a key that wraps around TPM. Decrypting of the data is done during boot process in order to bring up networking.
SYSTEM SETTINGS WRITE ACCESS
Only owners have permission to change system settings. Settingsd, a setting daemon, will be used to manage system setting write access and exploit settings in form appropriate to various services which needs them.
A random nonce is generated at each boot. If the owner logs into the system, the login process will hash the nonce with owner's password and pass the hash to settingsd and nonce to owner's session. When system setting changed, password will be prompted and the nonce will be hashed with it. It will then be used as HMAC the settings. This blob will be verified and applied to settingsd.
There are 3 user modes on a Chrome OS device. These modes are set by the owner of the device. Each of these modes serves a different purpose and offers different form of protection. The modes are whitelist mode, promiscuous mode and incognito mode.
On whitelist mode, only users in the whitelist and the owner can use the device. This is much like the other OS.
In promiscuous mode, owner chose to opt out whitelist. All users (with valid Google account) will get tmpfs home directory their settings will sync down from the cloud but it will only persist during the current session. No state is saved on the system.
Incognito mode is a stateless mode. There is no login required and data is only cached until session is over. No state is sync down from the cloud and no state from the current persists after termination. A tmpfs will be created to hold Chromium browser's session data and an instance of the browser will be opened. The session ends when the instance is closed and it will return to login screen.
In default settings, the whitelist option is selected while the Incognito mode option is not selected.
This section will cover security feature of Chrome OS.
SECURITY PRINCIPLES AND TYPE OF ATTACKS
Chrome OS is built with security as one of its prime aspects. 4 Guiding principles are used when designing security mechanism on Chrome OS. The principles are
The perfect is the enemy of the good. There is no perfect security. There will always be loop holes and vulnerabilities. Therefore the shipping of something that is very good must not be stop by things like searching for some perfect system.
Deploy defense in depth. Place in several lines of defense starting from entry point to the core of the system.
Make it secure by default. Treat security as a core component and not some advance feature or add-ons. Security should run side by side with applications.
Don't scapegoat our users. The web is very complexity. It is difficult to make accurate judgment of one's risk when facing such complexity. Therefore, system should keep user informed, ask lesser question and make decision on things which user can comprehend.
There are 2 types of attackers, an opportunistic attacker and a dedicated attacker. An opportunistic attacker will randomly choose his victim. He compromises his victim device by luring them through web sites or application. On the other hand, a dedicated attacker may target a particular victim. He is willing to steal the device for own uses. He is also willing to carry out DNS or other network attacks in order to compromise Chrome OS update or login processes. The threats are classified into 2 groups and they are remote system compromise and device theft. Remote system compromise means attacks on devices without any physical contact while device theft means attacks having physical contact on the devices.
PREVENTING REMOTE SYSTEM COMPROMISE
There are several ways which the attacker can compromise the OS. Due to this, it is important to exercise the principle of deploy defense in depth. There will be mechanisms that prevent an attack and multiple layers of protection to limit the damage done. The following describe some techniques to prevent an attack.
OS hardening. This is the lowest level of security strategy. It involves OS-level protection mechanisms and mitigation techniques. This protection can be use for both opportunistic and dedicated attack. The design relies on several independent techniques like process sandboxing, toolchain hardening, kernel hardening and configuration paring, additional file system restriction and others.
Modular Browser. It is easier to separate the OS functionality and sandbox different processes with increasing modularity. Therefore, security can be enhanced by looking at each area. Increase modularity also improves inter-process communication with Chromium, making it more efficient
Security in web application. An advantage of Chrome OS is that it allows web application to provide more functionality to user. However, this also opens up more areas for web-based attacks. Therefore, works have been done to allow Chrome OS to manage access to APIs in a unified manner. This allows user visibility to be integrated into the web application and also provide a way to granted permission to different applications.
Secure autoupdate. This is to prevent autoupdate to be attacked by the attackers. Some ways to do this is to signed updates download over SSL, no backwards movement of version number and verify each update on the subsequent boot.
Verified Boot. This process will ensure that the boot is not under attack or corruption. Instead of using trust platform module, Chrome OS uses a custom read-only firmware to perform integrity checks on writing firmware. The writing firmware will then verify the next component in the boot process. The design has 2 verification systems: Firmware-based verification and kernel-based verification. The 2 system is used to detect changes in boot time, provide secure recovery path so new installation is protected from past attacks.
PREVENTING DEVICE THEFT
When a device is stolen, the attacker may tries to hack into the system to get whatever data that is stored in it apart from reselling of the device. In order to prevent data theft, some methods are in place.
Data Protection. This is to prevent data from being read by others. Chrome OS does this by using encryption and limits access. Data stored in OS, browser and plug-in will be encrypted and different user cannot access each other data on a shared device.
Account Management. Prevent the attacker from logging onto the system. This is done by having system setting overwriting user preference. More details will be covered in later section.
Login. Chrome OS device authenticate user via 1) trying to reach Google Account online, 2) use password hash mapping to check for offline cache of user and 3) cache a mapping between the user and salted hash of password for every successful login.
PROTECTING STORED DATA
Chrome OS devices is designed for portability and sharing. Therefore, it is crucial to protect the privacy of user data. The problem arises when there are multiple users, portable devices and data that is stored locally. When there are multiple users, if data is not protected properly, one user will be able to see the other user data. As for portable and locally stored data, user may misplace or have their device stolen and therefore, some protection is needed to protect the user data. One way to do this is through encryption. Chrome OS designers, places encryption on individual user home directory, data created by plugins and data stored by HTML5 web application.
Each user is given an image file which is stored at the user specific directory using hash of user name with a salted value. A loop device is used to attach the image (a sparse file) to the system. Dm_crypt is place on top of the loop device using device mapper subsystem. The dm_crypt device is then formatted to an ext4 file system and copied into the user directory and it will be ready for use. Besides protecting the image, protecting the encryption key to the image is also important. Therefore, the encryption key for dm_crypt is generated randomly during setup using kernel random generator and hardware random generator (if exist). This key is then encrypted partial cryptographic hash gotten from user's password in Google account. When a password is changed, the encryption key is re-encrypted with hash generated from the new password. The encryption key is decrypted during login.
Performance issue comes when formatting of file system. It usually takes longer time to format a file system than a file. Therefore, lazy inode table initialization supported by ext4 is used to speedup the process.
MANAGING ENCRYPTION KEY
To improve the security of the encryption key, 2 methods is used. One is to use key strengthening technique to increase the time it takes to get the hash through brute force attack. Another method is to use trusted platform module (TPM) device. This limits the brute force attack without overhead of key strengthening. Both of these methods are implemented using memory-bound approach to speedup login.
HASHING USER NAME
Chrome OS uses hashing of user name to make a filesystem safe for use. The stronger the hash, the better the protection. In addition, hashed user name make it more difficult to determine the user name for a given device without carry out brute force attack.
RECLAIMING LOST SPACE
When user logouts, Chrome OS will attempts to any unused space from the sparse file. This is to reduce the size of the sparse for easy storage. However, reclaiming lost space in sparse file can be a problem due to file fragmentation. A possible solution to tackle this problem is to use ext4 defragmentation feature. Ext4 supports defragmentation of both local and mounted file system. Ext4 is also designed to minimized fragment during file allocation. With this, a background event-triggered daemon can be used to run checks for fragmentation when user is creating or deleting data.
System hardening is a technique that makes Chrome OS device tougher to be compromised by attacks using various system level mechanisms. Unlike other Linux distribution, all native applications on Chrome OS are known in advance as they are all web applications. Hence, it is easier to enforce comprehensive access control and exploit well-known mitigation techniques.
In effort to reduce surface attacks, Chrome OS will prevent process from accessing functions that is not required by applying "Principles of least privilege". This reduces the amount of code exposed at a time and thus reduces the risk of the codes having loop holes on security. Runtime and compile-time exploit mitigations are also to make successful attacks more difficult to achieve. These mitigations are used since it is impossible to isolate software completely to ensure there is no vulnerability.
There are 3 deployment phase in system hardening. In each phase different area of Chrome OS is hardened.
In phase 1, comprehensive userland isolation is carried out using 2 containment options. They are minijail and mandatory access control (MAC). Minijail is a small program that allows users to perform a range of behaviors during launching of new executables. It can enable/disable capabilities, dropping root (uid + gid), setting securebits (SECURE_NOROOT, SET_DUMPABLE) and setting rlimits. 2 MAC program is under consideration. They are Grsecurity and Tomoyo. Grsecurity is a better choice as it provides an effective automatic rule generator and lots of kernel hardening features and bug fixes. Tomoyo on the other hand, ensures process does not exceed their expected boundaries.
In phase 2, hardening on other parts of the system is done. This includes browser instance, net namespace, devices interposition and etc.
In the last phase, exploring and integrating new kernel and user space hardening techniques and research on isolating kernel space driver.
Chrome OS is built for speed, security and simplicity. With new concepts and innovative areas, the OS can several different modes of user interface giving users a view which they are most comfortable with. Chrome OS firmware is also striped off most of the unnecessary steps to provide very fast booting time. The main application of Chrome OS is the web therefore applications developed by any web technology will work with it. Although the web is a playground for attacks, the OS is equipped with multiple security measures to counter them. Security measures are also in place to protect user data in cases where physical device is stolen. Development of Chrome OS is still in progress and much of the feature describe here may be improved. Hence, we can expect a better and faster operating system after it is completed.