ChromeOS in Summary
- The OS is Chrome, basically
- All apps are web-based
- There's no permanent local storage and everything is stored on the Internet
- But thumb drives are supported
- Local config and cache are encrypted
- File browsing is done from within Chrome
- Music and videos, too
- There's no printing
- The OS is self-repairing at boot, probably limiting the customization
- But it's largely open source so you can customize and compile your own
- "They want, wherever feasible, to build on existing components and tools from the open source community without unnecessary re-invention. This clear focus should benefit a wide variety of existing projects and we welcome it."
- x86 and AMD64 are supported now
- ARM support is "coming soon."
- D-Bus: The browser uses D-Bus to interact with the rest of the system. Examples of this include the battery meter and network picker.
- Connection Manager: Provides a common API for interacting with the network devices, provides a DNS proxy, and manages network services for 3G, wireless, and ethernet.
- WPA Supplicant: Used to connect to wireless networks.
- Autoupdate: Our autoupdate daemon silently installs new system images.
- Power Management: (ACPI on Intel) Handles power management events like closing the lid or pushing the power button.
- xscreensaver: Handles screen locking when the machine is idle.
- Standard Linux services: NTP, syslog, and cron.
- Process sandboxing
- Mandatory access control implementation that limits resource, process, and kernel interactions
- Control group device filtering and resource abuse constraint
- Chrooting and process namespacing for reducing resource and cross-process attack surfaces
- Media device interposition to reduce direct kernel interface access from Chromium browser and plugin processes
- Toolchain hardening to limit exploit reliability and success
- NX, ASLR, stack cookies, etc
- Kernel hardening and configuration paring
- Additional file system restrictions
- Read-only root partition
- tmpfs-based /tmp
- User home directories that can't have executables, privileged executables, or device nodes
- Longer term, additional system enhancements will be pursued, like driver sandboxing
How encryption worksIn a nutshell, each user gets an encrypted image file in a hidden directory that is created at her first login. Thereafter, each time she logs in, the encrypted image is unlocked and made available for use. On logout or reboot, the user's data is locked away again. On some logouts, the encrypted image may be compacted. This step minimizes data loss due to file system fragmentation inside the image.
Find out more at .