diff options
Diffstat (limited to 'docs/rainbow.txt')
| -rw-r--r-- | docs/rainbow.txt | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/docs/rainbow.txt b/docs/rainbow.txt new file mode 100644 index 0000000..408eda9 --- /dev/null +++ b/docs/rainbow.txt @@ -0,0 +1,180 @@ +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. + |