Rainbow: Designing an Isolation Shell for Bitfrost ================================================== :Author Michael Stone michael@laptop.org :Acknowledgments Ivan Krstić, Noah Kantrowitz, Michael Burns, Bernardo Innocenti, Reynaldo Verdejo, Mitch Bradley (OLPC), James Cameron (Hewlett-Packard), Dave Woodhouse (Red Hat), Herbert Pötzl (Linux-VServer), Marcus Leech (Nortel), and Harry George (Boeing), all contributed to the design proposed in this this document. Steve Bellovin (Columbia), Daniel J. Bernstein (UIC), Eric S. Raymond, and the Plan 9 security team (Russ Cox, Eric Grosse, Rob Pike, Dave Presotto, and Sean Quinlan) all designed or documented software which inspired this proposal. :Metadata Revision: Draft-1 - release 1 Timestamp: Fri Oct 26 18:50:00 UTC 2007 Feedback URL: http://mailman.laptop.org/mailman/listinfo/security Authoritative version of this document: http://wiki.laptop.org/go/Rainbow We welcome feedback on this document, preferably to the public OLPC security mailing list, for which you can sign up at the feedback URL given above. If you strongly prefer to keep your comments private, you may mail the author of the document at the provided e-mail address. This is NOT the final version of the design. The contents of this document accurately reflect OLPC's thinking about security at the time of writing, but certain aspects of the security model may change before production. This document will be updated to reflect any such changes. The latest version of this document may be found at the authoritative version URL. 1. Foreword ----------- In early 2007, Ivan Krstić wrote that: "The 1971 version of UNIX supported the following security permissions on user files... what's deeply troubling... [is that] a user can choose to protect her files from other people on the system, but has no control whatsoever over what her own programs are able to do with her files." He further wrote that "the crux of the problem lies in the assumption that any program executing on a system on the user's behalf should have the exact same abilities and permissions as any other program executing on behalf of the same user." The task of implementing the security vision described in Bitfrost therefore devolves into (among others) the task of implementing an "isolation shell" - i.e. a shell that is capable of isolating programs running on the user's behalf from the full authority vested in that user. 2. Isolation Mechanisms ----------------------- There are two basic mechanisms for implementing isolation - namespaces and access checks. Namespace-derived isolation operates on the principle that agents are unable to manipulate resources that they cannot name. Access checks are simply attempts to discharge proof obligations of the form "agent A can manipulate resource R by method M". (While the proof obligations do not usually refer to other obligations, the assertions made by the system about the processes, resources, and methods in question are frequently higher-order.) Unix systems use both of these mechanisms to isolate agents (groups of processes) from named resources (memory pages, files, network interfaces, audio and video devices, other processes) that can be manipulated by several means including, most prominently, reading from them and writing to them. Its fundamental vehicle for both namespace isolation and access-control is the filesystem, wherein name visibility is controlled by both chroot() and directory read/execute bits, where the authority requirements that access control checks are recorded in tags attached to names, and where the authority to satisfy those access control checks is vested primarily in "user ids". 3. An Isolation Shell --------------------- Claim: Every protection described in Bitfrost §8 (excerpted below) can be implemented by a shell which generates a new uid for each privilege boundary it is asked to enforce. Justification: 8.1. P_BIOS_CORE: core BIOS protection 8.2. P_BIOS_COPY: secondary BIOS protection Pre-kernel protections. 8.3. P_SF_CORE: core system file protection Can be implemented by standard Unix file permissions and a mandatory request for the root password. 8.4. P_SF_RUN: running system file protection Can be implemented via a snapshotting filesystem (perhaps implemented on top of a CoW link primitive) or via unionfs. 8.5. P_NET: network policy protection Can be implemented with the "OWNER" netfilter match extension. 8.6. P_NAND_RL: NAND write/erase protection 8.7. P_NAND_QUOTA: NAND quota These require upstream support in JFFS2 regardless of which privilege delimiter is chosen. 8.8. P_MIC_CAM: microphone and camera protection These require upstream support, either in the IO subsystem (to close specified file descriptors) or in the camera and microphone drivers (to add a per-user/container on/off switch.) 8.9. P_CPU_RL: CPU rate limiting This can be hacked together with cputime limits and a stateful daemon or by patching the scheduler (as VServer does). 8.10. P_RTC: real time clock protection This can be implemented by protecting kernel memory and root. 8.11. P_DSP_BG: background sound permission This could be implemented in-driver or by directing all audio through a mixer. 8.12. P_X: X window system protection I believe but have not confirmed that XACE will be able to enforce authorization decisions made on a per-user basis. 8.13. P_IDENT: identity service This is unaffected by privilege separation. 8.14. P_SANDBOX: program jails This can be implemented either by being very careful with filesystem permissions or with hardened chroots. 8.15. P_DOCUMENT: file store service 8.16. P_DOCUMENT_RO: file store scanning This can be implemented by gating directory listing and traversal on a directory containing the stored documents. Stored documents can be made available to running activities either with hardlinks or bindmounts. 8.17. P_DOCUMENT_RL: file store rate limiting 8.18. P_DOCUMENT_BACKUP: file store backup service 8.19. P_THEFT: anti-theft protection 8.20. P_SERVER_AUTH: transparent strong authentication to trusted server 8.21. (For later implementation) P_PASSWORD: password protection All these permissions are unaffected by the privilege separation mechanism. 4. Conclusion ------------- A shell that, on human direction, isolates programs in the ways described by Bitfrost can be implemented solely on top of standard Unix permissions by carefully designing the permissions recorded in the initial filesystem, by controlling access to root's authority, and by inserting several uid/gid-based access checks in systems that currently lack them.