DOCSLIB.ORG

Protection Nov. 14, 2008 15-410

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Protection Nov. 14, 2008 15-410 15-410 “...1969 > 1999?...” Protection Nov. 14, 2008 Dave Eckhardt Roger Dannenberg 1 L32_Protection 15-410, F'08 Synchronization Project 3 due tonight Please remember to register for late days as appropriate One registration per day Please register for the midnight floppy disc seminar in the 5th floor lobby Registrations before 16:00 are most useful Carefully consider the P3extra overtime In general, getting a really solid kernel is the best thing » For your grade » For your education! So once the dust has settled, run all the tests and carefully read the P4 requirements If you know early that you will p3extra, please register early 2 15-410, F'08 Synchronization 15-610 (Spring '09) If you want hands-on experience with tricks of the trade N mini-projects: hints, prefetching, transactions, ... Small, intimate class Achievable without panic 15-412 (Fall '09) If 410 was fun... If you want to do more, If you want to see how it's done “in real life”, If you want to write real OS code used by real people, Consider 15-412 3 15-410, F'08 Synchronization Project 4 Monday's lecture might be beneficial 4 15-410, F'08 Outline Protection (Chapter 14) Protection vs. Security Domains (Unix, Multics) Access Matrix Concept, Implementation Revocation – not really covered today (see text) Mentioning EROS 5 15-410, F'08 Protection vs. Security Textbook's distinction Protection happens inside a computer Which parts may access which other parts (how)? Security considers external threats Is the system's model intact or compromised? 6 15-410, F'08 Protection Goals Prevent intentional attacks “Prove” access policies are always obeyed Detect bugs “Wild pointer” example Policy specifications System administrators Users - May want to add new privileges to system 7 15-410, F'08 Objects Hardware Exclusive-use: printer, serial port, CD writer, ... Fluid aggregates: CPU, memory, disks, screen Logical objects Files Processes TCP port 25 Database tables 8 15-410, F'08 Operations Depend on object! Disk: read_sector(), write_sector() CD-ROM: read_sector(...) TCP port: advertise(...) CPU Conceptually: context_switch(...), <interrupt> More sensibly: realtime_schedule(..., ...) 9 15-410, F'08 Access Control Basic access control Your processes should access only “your stuff” Implemented by many systems 10 15-410, F'08 Access Control Basic access control Your processes should access only “your stuff” Implemented by many systems Principle of least privilege (text: “need-to-know”) cc -c foo.c should read foo.c, stdio.h, ... should write foo.o should not write ~/.cshrc This is harder 11 15-410, F'08 Who Can Do What? access right = (object, operations) /etc/passwd, r /etc/passwd, r/w process protection domain P0 de0u, P1 rbd, ... protection domain list of access rights de0u (/etc/passwd, r), (/afs/andrew/usr/de0u/.cshrc, w) 12 15-410, F'08 Protection Domain Example Domain 1 /dev/null, read/write /usr/davide/.cshrc, read/write /usr/rbd/.cshrc, read Domain 2 /dev/null, read/write /usr/rbd/.cshrc, read/write /usr/davide/.cshrc, read 13 15-410, F'08 Using Protection Domains Least privilege requires domain changes Doing different jobs requires different privileges One printer daemon, N users Print each user's file with minimum necessary privileges... 14 15-410, F'08 Using Protection Domains Least privilege requires domain changes Doing different jobs requires different privileges One printer daemon, N users Print each user's file with minimum necessary privileges... Two general approaches Hold constant “process domain” mapping Requires domains to add and drop privileges User “printer” gets & releases permission to read your file Hold constant privileges of a domain Processes domain-switch between high-privilege, low- privilege domains Printer process opens file as you, opens printer as “printer” 15 15-410, F'08 Protection Domain Models Three sample models Domain = user Domain = process Domain = procedure (other models are possible) 16 15-410, F'08 Domain = User Object permissions depend on who you are All processes you are running share privileges Privilege adjustment? Log off, log on (i.e., domain switch) 17 15-410, F'08 Domain = Process Resources managed by special processes Printer daemon, file server process, ... Privilege adjustment? Objects cross domain boundaries via IPC “Please send these bytes to the printer” /* concept only; pieces missing */ s = socket(AF_UNIX, SOCK_STREAM, 0); connect(s, pserver, sizeof pserver); mh->cmsg_type = SCM_RIGHTS; mh->cmsg_len[0] = open(“/my/file”, 0, 0); sendmsg(s, &mh, 0); 18 15-410, F'08 Domain = Procedure Processor limits access at fine grain Hardware protection on a per-variable basis! Domain switch – Inter-domain procedure call nr = print(strlen(buf), buf); What is the “correct domain” for print()? Access to OS's data structures Permission to call OS's internal putbytes() Permission to read user's buf 19 15-410, F'08 Domain = Procedure Processor limits access at fine grain Hardware protection on a per-variable basis! Domain switch – Inter-domain procedure call nr = print(strlen(buf), buf); What is the “correct domain” for print()? Access to OS's data structures Permission to call OS's internal putbytes() Permission to read user's buf Ideally, correct domain automatically created by hardware Common case: “user mode” vs. “kernel mode” » Only a rough approximation of the right domain » But simple for hardware to implement 20 15-410, F'08 Unix “setuid” concept Assume Unix protection domain numeric user id Not the whole story! This overlooks: Group id, group vector Process group, controlling terminal Superuser But let's pretend for today Domain switch via setuid executable Special permission bit set with chmod u+s file Meaning: exec() sets uid to executable file's owner Gatekeeper programs “lpr ” run by anybody can access printer 's queue files 21 15-410, F'08 Access Matrix Concept Concept Formalization of “who can do what” Basic idea Store all permissions in a matrix One dimension is protection domains Other dimension is objects Entries are access rights 22 15-410, F'08 Access Matrix Concept File1 File2 File3 Printer D1 rwxd r D2 r rwxd w D3 rwxd rwxd rwxd w D4 r r r 23 15-410, F'08 Access Matrix Details OS must still define process domain mapping OS must define, enforce domain-switching rules Ad-hoc approach Special domain-switch rules (e.g., log off/on) Can encode domain-switch in access matrix! Switching domains is a privilege like any other... Add domain columns (domains are objects) Add switch-to rights to domain objects » “D2 processes can switch to D1 at will” Subtle (dangerous) 24 15-410, F'08 Adding “Switch-Domain” Rights File1 File2 File3 D1 D1 rwxd r D2 r rwxd s D3 rwxd rwxd rwxd D4 r r r 25 15-410, F'08 Updating the Matrix Ad-hoc approach “System administrator” can update matrix Matrix approach Add copy rights to objects Domain D1 may copy read rights for File2 So D1 can give D2 the right to read File2 26 15-410, F'08 Adding Copy Rights File1 File2 File3 D1 rwxdR r D2 r rwxd D3 rwxd rwxd rwxd D4 r r r 27 15-410, F'08 Adding Copy Rights File1 File2 File3 D1 rwxdR r D2 r r rwxd D3 rwxd rwxd rwxd D4 r r r 28 15-410, F'08 Updating the Matrix Add owner rights to objects D1 has owner rights for O47 D1 can modify the O47 column at will Can add, delete rights to O47 from all other domains Add control rights to domain objects D1 has control rights for D2 D1 can modify D2's rights to any object D1 may be teacher, parent, ... 29 15-410, F'08 Access Matrix Implementation Implement matrix via matrix? Huge, messy, slow Very clumsy for... “world readable file” Need one entry per domain Must fill rights in when creating new domain “private file” Lots of blank squares » Can Alice read the file? - No » Can Bob read the file? - No » ... Two typical approaches – “ACL”, “capabilities” 30 15-410, F'08 Access Control List File1 D1 D2 r D3 rwxd D4 r 31 15-410, F'08 Access Control List (ACL) List per matrix column (object) de0u, read; bmm, read+write Naively, domain = user AFS ACLs domain = user, user:group, system:anyuser, machine list (system:campushost) positive rights, negative rights de0u:staff rlid nwf -id Doesn't really do least privilege System stores many privileges per user, permanently... 32 15-410, F'08 Capability List File1 File2 File3 D1 rwxdR r 33 15-410, F'08 Capability Lists Capability Lists List per matrix row (domain) Naively, domain = user More typically, domain = process Permit least privilege Domains can transfer & forget capabilities Possible to create “just right” domains » cc which can't write to .cshrc Bootstrapping problem Who gets which rights at boot? Who gets which rights at login? Typical solution: store capability lists in files somehow 34 15-410, F'08 Mixed Approach Permanently store ACL for each file Must fetch ACL from disk to access file ACL fetch & evaluation may be long, complicated open() checks ACL, creates capability “Process 33 has read-only access to vnode #5894” Records access rights for this process Quick verification on each read(), write() Result: per-process fd table “caches” results of ACL checks 35 15-410, F'08 Internal Protection? Understood so far: Which user process should be allowed to access what? Job performed by OS How to protect OS code, data from user processes Hardware user/kernel boundary Can we do better? Can we protect parts of the OS from other parts? 36 15-410, F'08 Traditional OS Layers User Program Print
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]
  • 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]
  • 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]
  • 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.
    [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]
  • CHERI Instruction-Set Architecture
    UCAM-CL-TR-850 Technical Report ISSN 1476-2986 Number 850 Computer Laboratory Capability Hardware Enhanced RISC Instructions: CHERI Instruction-set architecture Robert N.M. Watson, Peter G. Neumann, Jonathan Woodruff, Jonathan Anderson, David Chisnall, Brooks Davis, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Michael Roe April 2014 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2014 Robert N.M. Watson, Peter G. Neumann, Jonathan Woodruff, Jonathan Anderson, David Chisnall, Brooks Davis, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Michael Roe SRI International is acknowledged as an additional copyright holder 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 document describes the rapidly maturing design for the Capability Hardware Enhanced RISC Instructions (CHERI) Instruction-Set Architecture (ISA), which is being developed by SRI International and the University of Cambridge. The document is intended to capture our evolving architecture, as it is being refined, tested, and formally analyzed. We have now reached 70% of the time for our research and development cycle. CHERI is a hybrid capability-system architecture that combines new processor primitives with the commodity 64-bit RISC ISA enabling software to efficiently implement fine-grained memory protection and a hardware-software object-capability security model. These extensions support incrementally adoptable, high-performance, formally based, programmer-friendly un- derpinnings for fine-grained software decomposition and compartmentalization, motivated by and capable of enforcing the principle of least privilege.
    [Show full text]
  • Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 6)
    UCAM-CL-TR-907 Technical Report ISSN 1476-2986 Number 907 Computer Laboratory Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 6) Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, John Baldwin, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son, Hongyan Xia April 2017 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2017 Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, John Baldwin, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son, Hongyan Xia, 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 Google SOAAP Focused Research Award, the RCUK’s Horizon Digital Economy Research Hub Grant (EP/G065802/1), the EPSRC REMS Programme Grant (EP/K008528/1), the EPSRC Impact Acceleration Account (EP/K503757/1), the Isaac Newton Trust, the UK Higher Education Innovation Fund (HEIF), Thales E-Security, ARM Ltd, and HP Enterprise.
    [Show full text]
  • A Survey of Distributed Capability File Systems and Their Application to Cloud Environments
    Calhoun: The NPS Institutional Archive Theses and Dissertations Thesis Collection 2014-09 A survey of distributed capability file systems and their application to cloud environments Jatho, Edgar W., III Monterey, California: Naval Postgraduate School http://hdl.handle.net/10945/43930 NAVAL POSTGRADUATE SCHOOL MONTEREY, CALIFORNIA THESIS A SURVEY OF DISTRIBUTED CAPABILITY FILE SYSTEMS AND THEIR APPLICATION TO CLOUD ENVIRONMENTS by Edgar W. Jatho, III September 2014 Thesis Co-Advisors: Peter Denning Mark Gondree Approved for public release; distribution is unlimited THIS PAGE INTENTIONALLY LEFT BLANK REPORT DOCUMENTATION PAGE Form Approved OMB No. 0704{0188 Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202{4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188) Washington DC 20503. 1. AGENCY USE ONLY (Leave Blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED 09-26-2014 Master’s Thesis 09-01-2013 to 09-26-2014 4. TITLE AND SUBTITLE 5. FUNDING NUMBERS A SURVEY OF DISTRIBUTED CAPABILITY FILE SYSTEMS AND THEIR APPLI- CATION TO CLOUD ENVIRONMENTS 6. AUTHOR(S) Edgar W. Jatho, III 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION REPORT NUMBER Naval Postgraduate School Monterey, CA 93943 9.
    [Show full text]
  • Navigating the Attack Surface
    Verify what? Navigating the Attack Surface Mark S. Miller, Google Formal Methods meets JavaScript Imperial College, March 2018 Risk as Attack Surface a Expected Risk: ∫likelihood * damage Potential damage Likelihood of exploitable vulnerability a Expected Risk: ∫likelihood * damage Resources to damage Fallible agents a Access Matrix Permission or Authority? Resources to damage Fallible agents a Hollow Out the Attack Surface! /etc/passwd Alan’s stuff Barb’s stuff Doug’s stuff Kernel + root OS’s TCB ~alan ~barb ~doug a Decouple accounts /etc/passwd Alan’s stuff Barb’s stuff Doug’s stuff Kernel + root OS’s TCB ~alan ~barb ~doug a a Decouple applications contact info pgp keyring calc.xls Net access Shell, Desktop Browser Spreadsheet Email client a Decouple apps contact info pgp keyring calc.xls Net access MobileOS Doug’s TCB Browser app Spreadsheet doc Mail a app Decouple apps contact info pgp keyring calc.xls Net access MobileOS Doug’s TCB Browser app Spreadsheet doc Mail a app Substrate Historical System System CMNM, Plessey 250, C.mmp, CM*, Crash-SAFE, CHERI, Risc-V Hardware CAP, Flex, IBM System/38, Intel 432 DVH, Hydra, StarOS, RATS, Capsicum, CloudABI, Genode, OS Cal-TSS, PSOS, NLTSS, Spring Barrelfish, Fuchsia Gnosis, KeyKOS, GuardOS, seL4 KeyKOS family OS EROS, CapROS, Coyotos Distributed OS Ameoba, Mach, Midori Gedanken, W7, J-Kernel, Joe-E, Emily, Monte, Frozen Realms, Language CaPerl, Caja, Tamed Pict, Plash shill, Wyvern, wasm-gc Act-1, Eden, Emerald, Pony, Kappa, Dr.SES Distributed Language Vulcan, Joule, E, Oz-E, M# Distributed Storage
    [Show full text]
  • CHERI Instruction-Set Architecture
    UCAM-CL-TR-850 Technical Report ISSN 1476-2986 Number 850 Computer Laboratory Capability Hardware Enhanced RISC Instructions: CHERI Instruction-set architecture Robert N.M. Watson, Peter G. Neumann, Jonathan Woodruff, Jonathan Anderson, David Chisnall, Brooks Davis, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Michael Roe April 2014 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2014 Robert N.M. Watson, Peter G. Neumann, Jonathan Woodruff, Jonathan Anderson, David Chisnall, Brooks Davis, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Michael Roe Sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contract FA8750-10-C-0237 (“CTSRD”) as part of the DARPA CRASH research program. 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 Defense Advanced Research Projects Agency or the Department of Defense. Portions of this work were sponsored by the RCUK’s Horizon Digital Economy Research Hub grant, EP/G065802/1. Portions of this work were sponsored by Google, Inc. 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 document describes the rapidly maturing design for the Capability Hardware Enhanced RISC Instructions (CHERI) Instruction-Set Architecture (ISA), which is being developed by SRI International and the University of Cambridge. The document is intended to capture our evolving architecture, as it is being refined, tested, and formally analyzed.
    [Show full text]
  • Capsicum: Practical Capabilities for UNIX
    Capsicum: practical capabilities for UNIX Robert N. M. Watson∗ and Jonathan Andersony Ben Laurie and Kris Kennaway University of Cambridge Google Computer Laboratory Belgrave House 15 JJ Thomson Avenue 76 Buckingham Palace Road Cambridge CB3 0FD London SW1W 9TQ United Kingdom United Kingdom frobert.watson, [email protected] fbenl, [email protected] 5 February, 2010 Abstract Capsicum is a lightweight operating system capability and sandbox framework planned for inclusion in FreeBSD 9. Capsicum extends, rather than replaces, UNIX APIs, providing new kernel primitives (sandboxed capability mode and capabilities) and a userspace sandbox API. These tools support the compartmentalization of monolithic UNIX applications into logical applications. We demonstrate our approach by adapting core FreeBSD utilities and Google’s Chromium web browser to use Capsicum primitives, and compare the complexity and robustness of Capsicum with other sandboxing techniques. 1 Introduction Capsicum is an API that brings capabilities to UNIX1. Capabilities are unforgeable tokens of authority, and have long been the province of research operating systems such as PSOS [16] and EROS [23]. UNIX systems have less fine-grained access control than capability systems, but are very widely deployed. By adding capability primitives to standard UNIX APIs, Capsicum gives application authors a realistic adoption path towards one of the ideals of OS security: least-privilege operation. Today, many popular, security-critical applications have been decomposed into parts with different priv- ilege requirements. Privilege separation, or compartmentalisation, is a pattern that has been adopted by ap- plications such as OpenSSH, Apple’s SecurityServer, and, more recently, Google’s Chromium web browser.
    [Show full text]