DOCSLIB.ORG

A Look at the EROS Operating System Jonathan S

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Look at the EROS Operating System Jonathan S A Look at the EROS Operating System Jonathan S. Shapiro Johns Hopkins University Abstract EROS is a capability-based, secure operating system originally designed to address the needs of shared computing utilities involving mutually suspicious users. The deploy­ ment plan for the original design was to provide leased compute service to competing business entities, potentially running on a single machine. As a result, the system was structured to preserve security in the face of both hostile dynamic content and hostile users. While the EROS platform can support the efficient deployment of multilevel se­ cure environments, it is primarily focused on business security requirements. These re­ quirements often address integrity as well as security concerns. An EROS-based deploy­ ment can ensure that business-critical data is manipulated exclusively by authorized ap­ plication software, which in turn is guarded against user tampering. Simultaneously, EROS enables users to run untrusted utility software, hand private or proprietary data to that software, and be assured (within reason) that the data cannot be disclosed to the out­ side world. This paper gives a general overview of the EROS system and what it can do. The EROS research project has now ended. Further work based on the EROS system is being pursued under the CapROS project (www.capros.org). The EROS team has moved on to a successor system: Coyotos (www.coyotos.org). 1 Introduction in other publications. Others result from chains of reasoning that are omitted for reasons of space. A This paper accompanies a talk for the 2005 Libre few are opinions derived from years of in-depth Software Meeting in Dijon, France. Since it seems experience with a range of operating systems. In likely that this will be the last non-academic publi­ an academic paper these statements would be inap­ cation on the EROS system, it has emerged as a propriate, but this paper is not aimed at an academ­ curiously informal mix of anecdote and paper. I ic audience. wanted to provide not just a sense of what EROS The EROS system is slowly taking on a life of its can do, but also a sense of its history and rationale. own. EROS is having significant influence on the In this paper I will try to describe how the EROS successor to the current L4 system, which is on its project got started, what is different and significant way to being a pure, capability-based nucleus. The about the system, and why EROS or its successor EROS code base itself has now been taken over by might be interesting as a secure operating system Charlie Landau under the CapROS project (www.­ platform for future applications. capros.org). This seems fitting, since Charlie was EROS is a difficult system to get your head one of the original KeyKOS architects. My own around, because it challenges many of the accepted wisdoms of conventional operating system design. Trying to approach this system by asking how it is Copyright 2005, Jonathan S. Shapiro. like other systems that you may know is often a Verbatim copying and distribution of this document in frustrating exercise. EROS is simply different. any medium are permitted without royalty or fee, pro­ One note to academic readers: there are some con­ vided that this copyright notice is preserved. clusions stated in this paper that are neither sub­ This paper was first published as part of the Libre Soft­ stantiated nor explained here. Some are addressed ware Meeting, Dijon, France, July 5-9, 2005 1 work has turned to a high-assurance successor sys­ sition from selling 7 copies of the system at $1 tem called Coyotos (www.coyotos.org). million each to selling 1 million copies at $7 As a research system, EROS has met essentially each.º all of the goals that we set for it. Minor changes My first introduction to KeyKOS came through a will be needed to move it into production use, but talk given by Norm Hardy at Stanford University these do not appear to be especially difficult. in 1989. Two years later I encountered it again as one of the founders of HaL Computer Systems. 2 How the EROS Project Started We briefly considered acquiring Key Logic, which had a strong engineering team and an extremely Like the LINUX system, EROS started its life as robust implementation. HaL©s goal was to deliver a an attempt to provide an open source reverse engi­ top to bottom line of systems that would be based neering of an existing operating system: KeyKOS. on open software standards, but would provide the Since there is a useful business lesson in it for oth­ kinds of reliability that IBM customers had come er open source projects, I©ll give a brief history to count on. To put some perspective on this, here. there is no UNIX-based system today (2005) that delivers the level of reliability routinely achieved 2.1 GNOSIS and KeyKOS by KeyKOS on less reliable hardware in 1990. As HaL©s manager of software design and one of the The GNOSIS project was started by Tymshare, founders, I was extensively involved in evaluating Inc. in 1972. The system first ran commercial ap­ the KeyKOS system. plications in 1983. For history fans, 1983 was also the year that UNIX System V and the 4.2 BSD Two conclusions came out of that evaluation: UNIX systems released. The Tymshare system was named originally named GNOSIS (ªGreat Cary Liu, our manager for the operating system New Operating System In the Skyº1), and the key group, felt strongly that HaL would be better technical contributors were Norm Hardy, Charlie served by porting UNIX System V Release 4, a Landau, Bill Frantz, Alan Bomberger, and Susan system that he had extensive experience with. Rajunas. There is a paper describing the architec­ Among other issues, Cary felt that he could hire ture of this system.2 It is definitely a contender for developers to work on it who already knew the the title of ªdensest piece of technical writing ever code base, and that this was critical to HaL©s crafted in the history of computing.º chances of success. In 1985, the GNOSIS system was spun out into a I concluded that KeyKOS was far better than new company called Key Logic, Inc., and the sys­ anything else I had seen, including SVR4. tem©s name changed to KeyKOS. Key Logic was Which is kind of ironic in hindsight, because I funded by Omron, Inc. to create a robust, secure had been the lead person in instigating the operating system for the Luna 88K line of work­ MIPS Application Binary Interface for SVR4 stations. The technical effort was completed just in while at Silicon Graphics, and I had come to time for Omron to abandon the workstation busi­ SGI from the language tools group at AT&T ness. Following this misfortune, Key Logic proved Bell Laboratories (home of SVR4). unable to make the transition to a world of com­ modity PCs, and ceased operations in 1990 after I should add that Cary was absolutely right about meeting every technical challenge they set out to this decision. Among other factors, HaL©s global address. As it was described to me at the time, they deployment partners were all committed to SVR4 were ªunable to make the necessary business tran­ as a software platform in some form, and transi­ tioning them to another operating system, no mat­ 1 The names ªGNOSISº and ªEROSº are a fairly convincing ter how compelling, would probably have been demonstration that technical people should not make impor­ impossible. tant marketing decisions. 2 See http://www.cis.upenn.edu/~KeyKOS/, in particular The There are two business lessons here. The first is KeyKOS Architecture. that managing a technology through a market dis­ 2 ruption (the introduction of the PC and the work­ of anything unpublished or proprietary. Which station) is extremely difficult under the best of cir­ was how EROS really got started. After a year of cumstances. In hindsight, it©s clear that KeyKOS part-time effort, EROS version 0.1 booted success­ went after the wrong niche. You don©t succeed in a fully on an i386 machine in early 1992, just in technology business by taking on an entrenched time to teach me about what happens when you competitor in an established market first. have a total hard disk failure and no backups. I ­ The second lesson is that Key Logic made several took a year out to recover by negotiating and man ­ critical mistakes in their financing. Tom O©Rourke, aging the spin out of the Xanadu Operating Com pany from Autodesk, which is an adventure for an­ who had also been the founder and CEO at 4 Tymshare, had learned how to start and run a com­ other paper some day. pany in a different generation, and I think he may not have realized just how much the world had 2.3 The Penn Years changed and how cut-throat the industry would Needing to recover from my recovery, I decided to ­ turn out to be during the 1990s. He needed multi return to school, and entered the PhD program at ple backers who were willing to play for high the University of Pennsylvania. Inevitably, the stakes and force him to articulate a viable business EROS project came with me. By this point some model. What he got was a single, conservative, questions had emerged in my mind about corporate investor that decided the stakes were too KeyKOS. The main issue concerned a claim that high, and backed out of the entire industry just as we had made in a paper entitled The KeyKOS it was becoming really interesting.
Load more

Recommended publications
  • CHERI Instruction-Set Architecture
    UCAM-CL-TR-876 Technical Report ISSN 1476-2986 Number 876 Computer Laboratory Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son September 2015 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2015 Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son, SRI International Approved for public release; distribution is unlimited. Sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C-0237 (“CTSRD”) and FA8750-11-C-0249 (“MRC2”) as part of the DARPA CRASH and DARPA MRC research programs. The views, opinions, and/or findings contained in this report are those of the authors and should not be interpreted as representing the official views or policies, either expressed or implied, of the Department of Defense or the U.S. Government. Additional support was received from St John’s College Cambridge, the SOAAP Google Focused Research Award, the RCUK’s Horizon Digital Economy Research Hub Grant (EP/G065802/1), the EPSRC REMS Programme Grant (EP/K008528/1), the Isaac Newton Trust, the UK Higher Education Innovation Fund (HEIF), and Thales E-Security. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Abstract This technical report describes CHERI ISAv4, the fourth version of the Capability Hardware Enhanced RISC Instructions (CHERI) Instruction-Set Architecture (ISA)1 being developed by SRI International and the University of Cambridge.
    [Show full text]
  • Access Control and Operating System
    Outline (may not finish in one lecture) Access Control and Operating Access Control Concepts Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks OS Mechanisms Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • Common Criteria • Amoeba • Windows 2000 – Distributed, capabilities certification • Unix Some Limitations – File system, Setuid • Information flow • Windows • Covert channels – File system, Tokens, EFS • SE Linux – Role-based, Domain type enforcement Access control Access control matrix [Lampson] Common Assumption Objects • System knows who the user is File 1 File 2 File 3 … File n – User has entered a name and password, or other info • Access requests pass through gatekeeper User 1 read write - - read – OS must be designed monitor cannot be bypassed User 2 write write write - - Reference Subjects monitor User 3 - - - read read User process ? Resource … User m read write read write read Decide whether user can apply operation to resource Two implementation concepts Capabilities Access control list (ACL) File 1 File 2 … Operating system concept • “… of the future and always will be …” • Store column of matrix User 1 read write - Examples with the resource User 2 write write - • Dennis and van Horn, MIT PDP-1 Timesharing Capability User 3 - - read • Hydra, StarOS, Intel iAPX 432, Eros, … • User holds a “ticket” for … • Amoeba: distributed, unforgeable tickets each resource User m read write write • Two variations References – store
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems
    Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems Anna Lyons Submitted in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computer Science and Engineering University of New South Wales Sydney, Australia September 2018 Abstract Criticality of a software system refers to the severity of the impact of a failure. In a high-criticality system, failure risks significant loss of life or damage to the environ- ment. In a low-criticality system, failure may risk a downgrade in user-experience. As criticality of a software system increases, so too does the cost and time to develop that software: raising the criticality also raises the assurance level, with the highest levels requiring extensive, expensive, independent certification. For modern cyber-physical systems, including autonomous aircraft and other vehicles, the traditional approach of isolating systems of different criticality by using completely separate physical hardware, is no longer practical, being both restrictive and inefficient. The result is mixed-criticality systems, where software applications with different criticalities execute on the same hardware. Sufficient mechanisms are required to ascertain that software in mixed-criticality systems is sufficiently isolated, otherwise, all software on that hardware is promoted to the highest criticality level, driving up costs to impractical levels. For mixed-criticality systems to be viable, both spatial and temporal isolation are required. Current aviation standards allow for mixed-criticality systems where temporal and spatial resources are strictly and statically partitioned in time and space, allowing some improvement over fully isolated hardware. However, further improvements are not only possible, but required for future innovation in cyber-physical systems.
    [Show full text]
  • Os Verification - a Survey As a Source of Future Challenges
    International Journal of Computer Science & Engineering Survey (IJCSES) Vol.6, No.4, August 2015 OS VERIFICATION - A SURVEY AS A SOURCE OF FUTURE CHALLENGES Kushal Anjaria and Arun Mishra Department of Computer Science &Engineering, DIAT, Pune, India ABSTRACT Formal verification of an operating system kernel manifests absence of errors in the kernel and establishes trust in it. This paper evaluates various projects on operating system kernel verification and presents in- depth survey of them. The methodologies and contributions of operating system verification projects have been discussed in the present work. At the end, few unattended and interesting future challenges in operating system verification area have been discussed and possible directions towards the challenge solution have been described in brief. KEYWORDS Formal verification, operating system, kernel. 1. INTRODUCTION The security and reliability of computer system is dependent on the underlying operating system kernel; kernel is the core of operating system. The kernel provide mechanism for user level applications to access hardware, scheduling and inter-process communication. Therefore, if anything goes wrong in the kernel while programming or implementation, it will affect the operation of entire system. To ensure the correct working of a kernel, testing and/or verification techniques have been used. Testing reduces frequency of failures, while verification detects errors and eliminates failures. Consider the fragment of C code shown in figure-1 int div(int p, int q) { int r; if (p<q) r=p/q; else r=q/p; return r; } Figure1. Fragment of C code Here r being an integer, if testing has been performed with p=8, q=4 and p=16, q=32, full coverage of code can be achieved.
    [Show full text]
  • Acknowledgments Preface 1 Overview I MICRO ERNEL ABSTRACTIONS
    Coyotos Microkernel Specification http://coyotos.org/docs/ukernel/spec.html Coyotos Microkernel Specification Version 0.3+ March 20, 2006 Jonathan S. Shapiro, Ph.D., Eric Northup, M. Scott Doerrie, Swaroop Sridhar Systems Research Laboratory Dept. of Computer Science Johns Hopkins University Neal H. Walfield, Marcus Brinkmann GNU Hurd Project Copyright 2006, Jonathan S. Shapiro. Verbatim copies of this document may be duplicated or distributed in print or electronic form for non-commercial purposes. Legal Notice THIS SPECIFICATION IS PROVIDED ``AS IS'' WITHOUT ANY WARRANTIES, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Table of Contents Acknowledgments Preface The Original Plan Overrun by the Hurd Coyotos: Take II A Brief Word on Terminology 1 Overview 1.1 Microkernel Objects 1.2 Sender Capabilities 1.3 Activations 1.4 Messages 1.5 Naming and Invocation 1.6 Exception and Interrupt Handling 1.7 Protection Model I MICROKERNEL ABSTRACTIONS 2 Capabilities 2.1 Representation 2.1.1 Capabilities to Memory Objects 2.1.2 Message-Related Capabilities 2.1.3 Capabilities to Processes 2.1.4 Miscellaneous Capabilities 2.2 Validity 2.3 Extensibility 3 Processes 3.1 State of a Process 3.2 FCRBs 3.3 Execution Model 3.3.1 Event Arrival and Run-In 3.3.2 Preemption 3.3.3 Exception Handling 1 of 38 04/10/06 11:19 Coyotos Microkernel Specification http://coyotos.org/docs/ukernel/spec.html 3.4 Event Delivery 4 Address Spaces 4.1 Memory
    [Show full text]
  • Operating System Verification—An Overview
    Sadhan¯ a¯ Vol. 34, Part 1, February 2009, pp. 27–69. © Printed in India Operating system verification—An overview GERWIN KLEIN Sydney Research Laboratory, NICTA,∗ Australia, School of Computer Science and Engineering, University of New South Wales, Sydney, Australia e-mail: [email protected] Abstract. This paper gives a high-level introduction to the topic of formal, interactive, machine-checked software verification in general, and the verification of operating systems code in particular. We survey the state of the art, the advantages and limitations of machine-checked code proofs, and describe two specific ongoing larger-scale verification projects in more detail. Keywords. Formal software verification; operating systems; theorem proving. 1. Introduction The fastest, cheapest and easiest way to build something is properly the first time (Parker 2007). This engineer’s credo has made it into popular literature, but it seems to be largely ignored in the world of software development. In the late 1960s a software crisis was diagnosed on a summit in the Bavarian Alps (Naur & Randell 1969): Software was getting more and more complex, and we had no structured way of building it. We ended up with projects that took significantly longer than planned, were more expensive than planned, delivered results that did not fully address customer needs, or at worst were useless. This summit in the late 1960s is widely seen as the birth of the discipline of software engineering. Now, almost 40 years later, we have come a long way. There are numerous books on software engineering, a plenitude of methodologies, programming languages, and processes to choose from.
    [Show full text]
  • Scalability of Microkernel-Based Systems
    Scalability of Microkernel-Based Systems Zur Erlangung des akademischen Grades eines DOKTORS DER INGENIERWISSENSCHAFTEN von der Fakultat¨ fur¨ Informatik der Universitat¨ Fridericiana zu Karlsruhe (TH) genehmigte DISSERTATION von Volkmar Uhlig aus Dresden Tag der mundlichen¨ Prufung:¨ 30.05.2005 Hauptreferent: Prof. Dr. rer. nat. Gerhard Goos Universitat¨ Fridericiana zu Karlsruhe (TH) Korreferent: Prof. Dr. sc. tech. (ETH) Gernot Heiser University of New South Wales, Sydney, Australia Karlsruhe: 15.06.2005 i Abstract Microkernel-based systems divide the operating system functionality into individ- ual and isolated components. The system components are subject to application- class protection and isolation. This structuring method has a number of benefits, such as fault isolation between system components, safe extensibility, co-existence of different policies, and isolation between mutually distrusting components. How- ever, such strict isolation limits the information flow between subsystems including information that is essential for performance and scalability in multiprocessor sys- tems. Semantically richer kernel abstractions scale at the cost of generality and mini- mality–two desired properties of a microkernel. I propose an architecture that al- lows for dynamic adjustment of scalability-relevant parameters in a general, flex- ible, and safe manner. I introduce isolation boundaries for microkernel resources and the system processors. The boundaries are controlled at user-level. Operating system components and applications can transform their semantic information into three basic parameters relevant for scalability: the involved processors (depending on their relation and interconnect), degree of concurrency, and groups of resources. I developed a set of mechanisms that allow a kernel to: 1. efficiently track processors on a per-resource basis with support for very large number of processors, 2.
    [Show full text]
  • Introduction Course Outline Why Does This Fail? Lectures Tutorials
    Course Outline • Prerequisites – COMP2011 Data Organisation • Stacks, queues, hash tables, lists, trees, heaps,…. Introduction – COMP2021 Digital Systems Structure • Assembly programming • Mapping of high-level procedural language to assembly COMP3231/9201/3891/9283 language – or the postgraduate equivalent (Extended) Operating Systems – You are expected to be competent Kevin Elphinstone programmers!!!! • We will be using the C programming language – The dominant language for OS implementation. – Need to understand pointers, pointer arithmetic, explicit 2 memory allocation. Why does this fail? Lectures • Common for all courses (3231/3891/9201/9283) void func(int *x, int *y) • Wednesday, 2-4pm { • Thursday, 5-6pm *x = 1; *y = 2; – All lectures are here (EE LG03) – The lecture notes will be available on the course web site } • Available prior to lectures, when possible. void main() – The lecture notes and textbook are NOT a substitute for { attending lectures. int *a, *b; func(a,b); } 3 4 Tutorials Assignments • Assignments form a substantial component of • Start in week 2 your assessment. • A tutorial participation mark will • They are challenging!!!! – Because operating systems are challenging contribute to your final assessment. • We will be using OS/161, – Participation means participation, NOT – an educational operating system attendance. – developed by the Systems Group At Harvard – Comp9201/3891/9283 students excluded – It contains roughly 20,000 lines of code and comments • You will only get participation marks in your enrolled tutorial. 5 6 1 Assignments Assignments • Assignments are in pairs • Don’t under estimate the time needed to do the – Info on how to pair up available soon assignments. • We usually offer advanced versions of the – ProfQuotes: [About the midterm] "We can't keep you working assignments on it all night, it's not OS.“ Ragde, CS341 – Available bonus marks are small compared to amount of • If you start a couple days before they are due, you will be late.
    [Show full text]
  • El Debat Polític D'ahir; Al Parlament De La Repúb Ica, Desenrotllat En
    EL TEMPS. - Al pla de Lleida, Penedès, Bages I Via, hi ha bol· res matinals. Per tota la resta de catalunya el cel està completament se~. pel qual motiu les glaçades I gebrades són tmpartants, I ha experimentat la temperatura un notable descens. Les mlnlmes registrades ahir han tingut lloc a Núria amb 11 graus sota zero I a Adrall I Sant Juilià de VIlatorta, amb 6 graus sota zero. IV _ Núm. 700 - Preue 10 cèntims AnY fundadort LLUIS COMPANYS Barcelona, dijous, s de febrer del 19J4 El MOMENT POUTIC El debat polític d'ahir; al Parlament de la Repúb ica, desenrotllat en un ambient de gran passió, vé a augnientar el confusionisme actual - o Uftfi[H[IA ~·~HJI11IUA[II A~~~R~A IPrieto, en nom dels socialistes, s'expresà en SENSE AUTORITAT NI GAllARDIA termes de gran violència.-Segueix la divisió l dintre el Govern lerroux, destacada novament e S darreres hores A despit de la votació de coníiança al Govern Lerroux, obtingudR en la intervenció de Martínez Barrio del Govern Lerroux després de l'apassionat debat parlamentari d'ahir, la situació politica segueiX més con1usa que mat. Si la crisi era inevitable abans d'ahir, ho és Proposicions llei sobre intensificació del Cultiu. la situació social als camps i espe­ El senyor ALVAREZ MENDIZA­ cialment a la provincia de Jaén. (Crònica del nostre redactor a Madrid Alard Prats) .rob apremiant urgencia des d'avui. La sessió parlamentària tingué l'ab· Madrid, 7. - A dos quarts i cmc surd& conseqi.ièncJa de complicar com mat la situació 1 de posar de re­ BAL presenta una esmena en la L'efervescencia que s'observa al carrer, ha tingut per fi ressò al Parla­ minuts de cinc comença la sess10 com lleu en el saló de sessions la profunda esquerda del gabinet, sense solda­ qual demana que es determinin El debat polític ment.
    [Show full text]
  • Labels and Event Processes in the Asbestos Operating System
    Labels and Event Processes in the Asbestos Operating System Petros Efstathopoulos∗ Maxwell Krohn† Steve VanDeBogart∗ Cliff Frey† David Ziegler† Eddie Kohler∗ David Mazieres` ‡ Frans Kaashoek† Robert Morris† ∗UCLA †MIT ‡Stanford/NYU http://asbestos.cs.ucla.edu/ ABSTRACT purposes [20]. Most servers instead revert to the most insecure de- sign, monolithic code running with many privileges. It should come Asbestos, a new prototype operating system, provides novel la- as no surprise that high-impact breaches continue. beling and isolation mechanisms that help contain the effects New operating system primitives are needed [21], and the best of exploitable software flaws. Applications can express a wide place to explore candidates is the unconstrained context of a new range of policies with Asbestos’s kernel-enforced label mechanism, OS. Hence the Asbestos operating system, which can enforce strict including controls on inter-process communication and system- application-defined security policies even on efficient, unprivileged wide information flow. A new event process abstraction provides servers. lightweight, isolated contexts within a single process, allowing the same process to act on behalf of multiple users while preventing Asbestos’s contributions are twofold. First, all access control it from leaking any single user’s data to any other user. A Web checks use Asbestos labels, a primitive that combines advantages server that uses Asbestos labels to isolate user data requires about of discretionary and nondiscretionary access control. Labels deter- 1.5 memory pages per user, demonstrating that additional security mine which services a process can invoke and with which other can come at an acceptable cost. processes it can interact.
    [Show full text]
  • Analysing the Security Properties of Object-Capability Patterns
    Analysing the Security Properties of Object-Capability Patterns Toby Murray Hertford College Oxford University Computing Laboratory A thesis submitted for the degree of Doctor of Philosophy Hilary Term, 2010 This thesis is dedicated to Bel, who has taught me more than anyone else. Acknowledgements Thanks firstly to my supervisor, Gavin Lowe, whose conscientious and ded- icated supervision of this work improved it, and its presentation, more than I can say, and whose wisdom and guidance were invaluable throughout this entire process. I couldn't have asked for a better supervisor. Gavin also contributed directly to the development of valuable parts of this work, as explained in the statement of authorship that follows. Thanks to Fred Spiessens and Bill Roscoe for examining this thesis. Thanks to Andrew Simpson and Bill Roscoe for their advice and feedback on this work as it progressed during my transfer and confirmation of status. Thanks to Bill Roscoe for valuable discussions about CSP and to Fred Spiessens for the same regarding Scoll and authority. Thanks to the anonymous reviewers of [ML09b] and [ML09a], and those at NICTA, whose feedback helped to improve the presentation in Chapter5. Thanks to David Wagner for useful discussions about authority and cau- sation that ultimately influenced the work in Chapter7, and for indirectly bringing to my attention the need to consider vulnerabilities due to recursive invocation. Thanks to Bill Frantz, David-Sarah Hopwood, Matej Koˇs´ık, Charles Landau, Alex Murray, Mark Seaborn and David Wagner, who helped me assemble Table 2.1. Thanks to all of the people on cap-talk and e-lang, including Mark Miller and Jonathan Shapiro, and all of my old workmates from DSTO's Annex project.
    [Show full text]