Secure Capability Systems
Total Page:16
File Type:pdf, Size:1020Kb
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. -
FIDO Technical Glossary
Client to Authenticator Protocol (CTAP) Implementation Draft, February 27, 2018 This version: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id- 20180227.html Previous Versions: https://fidoalliance.org/specs/fido-v2.0-ps-20170927/ Issue Tracking: GitHub Editors: Christiaan Brand (Google) Alexei Czeskis (Google) Jakob Ehrensvärd (Yubico) Michael B. Jones (Microsoft) Akshay Kumar (Microsoft) Rolf Lindemann (Nok Nok Labs) Adam Powers (FIDO Alliance) Johan Verrept (VASCO Data Security) Former Editors: Matthieu Antoine (Gemalto) Vijay Bharadwaj (Microsoft) Mirko J. Ploch (SurePassID) Contributors: Jeff Hodges (PayPal) Copyright © 2018 FIDO Alliance. All Rights Reserved. Abstract This specification describes an application layer protocol for communication between a roaming authenticator and another client/platform, as well as bindings of this application protocol to a variety of transport protocols using different physical media. The application layer protocol defines requirements for such transport protocols. Each transport binding defines the details of how such transport layer connections should be set up, in a manner that meets the requirements of the application layer protocol. Table of Contents 1 Introduction 1.1 Relationship to Other Specifications 2 Conformance 3 Protocol Structure 4 Protocol Overview 5 Authenticator API 5.1 authenticatorMakeCredential (0x01) 5.2 authenticatorGetAssertion (0x02) 5.3 authenticatorGetNextAssertion (0x08) 5.3.1 Client Logic 5.4 authenticatorGetInfo (0x04) -
SCALABLE CAPABILITY-BASED AUTHORIZATION for HIGH- PERFORMANCE PARALLEL FILE SYSTEMS Nicholas Mills Clemson University, [email protected]
Clemson University TigerPrints All Theses Theses 5-2011 SCALABLE CAPABILITY-BASED AUTHORIZATION FOR HIGH- PERFORMANCE PARALLEL FILE SYSTEMS Nicholas Mills Clemson University, [email protected] Follow this and additional works at: https://tigerprints.clemson.edu/all_theses Part of the Computer Engineering Commons Recommended Citation Mills, Nicholas, "SCALABLE CAPABILITY-BASED AUTHORIZATION FOR HIGH-PERFORMANCE PARALLEL FILE SYSTEMS" (2011). All Theses. 1131. https://tigerprints.clemson.edu/all_theses/1131 This Thesis is brought to you for free and open access by the Theses at TigerPrints. It has been accepted for inclusion in All Theses by an authorized administrator of TigerPrints. For more information, please contact [email protected]. SCALABLE CAPABILITY-BASED AUTHORIZATION FOR HIGH-PERFORMANCE PARALLEL FILE SYSTEMS A Thesis Presented to the Graduate School of Clemson University In Partial Fulfillment of the Requirements for the Degree Master of Science Computer Engineering by Nicholas L. Mills May 2011 Accepted by: Dr. Walter B. Ligon III, Committee Chair Dr. Richard R. Brooks Dr. Adam W. Hoover Abstract As the size and scale of supercomputers continues to increase at an exponential rate the number of users on a given supercomputer will only grow larger. A larger number of users on a supercomputer places a greater importance on the strength of information security. Nowhere is this requirement for security more apparent than the file system, as users expect their data to be protected from accidental or deliberate modification. In spite of the ever-increasing demand for more secure file system access the majority of parallel file systems do not implement a robust security protocol for fear it will negatively impact the performance and scalability of the file system. -
Discretionary Access Control
Part IV Access Control Confidentiality and integrity are often enforced using a form of authorization known as access control, which involves the following assumptions. • Predefined operations are the sole means by which principals can learn or update information. • A reference monitor is consulted whenever one of these predefined oper- ations is invoked; the operation is allowed to proceed only if the invoker holds the required privileges. Confidentiality then is achieved by restricting whether a given principal is au- thorized to execute operations that reveal information; integrity is achieved by restricting execution of operations that perform updates. An access control policy specifies which of the operations associated with any given object (including operations to change the policy) each given principal1 is authorized to have performed. Principals are entities to which execution can be attributed|users, processes, threads, or even procedure activations. Ob- jects are entities on which operations are defined—storage abstractions, such as memory or files (with read, write, and execute operations), and code ab- stractions, such as modules or services (with operations to initiate or suspend execution). Distinct privileges are typically associated with distinct operations, and sometimes there are distinct privileges for each different operation on each different object. So, for example, there might be a specific privilege readObj that a principal must hold to perform operation read on object Obj. The Principle of Least Privilege is best served by having fine-grained princi- pals, objects, and operations; the Principle of Failsafe Defaults favors defining an access control policy by enumerating privileges rather than prohibitions. That, however, is only a small part of the picture, and there is much ground to cover in our discussions of access control policy. -
The Confused Deputy Problem(Or Why Capabilities Might Have Been Invented)
The confused deputy problem(Or why capabilities might have been invented) st Berlin, 21 ,November 2014 The confused deputy | P.Jagannatha | Computer Security Seminar A very powerful program - a program that can delete all your files - a program that can scan your email for interesting tidbits. Many of us spend hours running this program. What is this program? A computer game --and every other program we use The only rights the game really needs to do its job are the ability to write in its window and to receive UI events directed at its window. Yet -- like every other program we execute -- it runs with a lot more rights than that. It runs with all of our authority. The confused deputy | P.Jagannatha | Computer Security Seminar Power is dangerous. While the game probably doesn’t do any of those things, if it became corrupted by a virus, it could The less power we give to a program, the less harm it can do when it runs. In general, giving every program we run access to all our files is dangerous, because if any of those programs get compromised, our files would be lost The solution is obvious: we should only grant a program the rights it needs to do its job, and no more. The same goes for every other application we run. The goal of object capabilities is to make that easier. The confused deputy | P.Jagannatha | Computer Security Seminar Content – Introduction – Analysis of the confused deputy problem – Examples – Ambient authority – Solution-capabilities – Advantages – D iscussion The confused deputy | P.Jagannatha | Computer Security Seminar Introduction - Deputy Client Deputy Resource Human -Confidence trick being Definitions: Application Programs that take actions on the behalf of other programs are deputies andInfrast needructur eappropriate permissions for their duties. -
Capability Myths Demolished
Capability Myths Demolished Mark S. Miller Ka-Ping Yee Jonathan Shapiro Combex, Inc. University of California, Berkeley Johns Hopkins University [email protected] [email protected] [email protected] ABSTRACT The second and third myths state false limitations on We address three common misconceptions about what capability systems can do, and have been capability-based systems: the Equivalence Myth (access propagated by a series of research publications over the control list systems and capability systems are formally past 20 years (including [2, 3, 7, 24]). They have been equivalent), the Confinement Myth (capability systems cited as reasons to avoid adopting capability models cannot enforce confinement), and the Irrevocability and have even motivated some researchers to augment Myth (capability-based access cannot be revoked). The capability systems with extra access checks [7, 13] in Equivalence Myth obscures the benefits of capabilities attempts to fix problems that do not exist. The myths as compared to access control lists, while the Confine- about what capability systems cannot do continue to ment Myth and the Irrevocability Myth lead people to spread, despite formal results [22] and practical see problems with capabilities that do not actually exist. systems [1, 9, 18, 21] demonstrating that they can do these supposedly impossible things. The prevalence of these myths is due to differing inter- pretations of the capability security model. To clear up We believe these severe misunderstandings are rooted the confusion, we examine three different models that in the fact that the term capability has come to be have been used to describe capabilities, and define a set portrayed in terms of several very different security of seven security properties that capture the distinctions models. -
On Access Checking in Capability-Based Systems1
On Access Checking in Capability-Based Systems1 Richard Y. Kain Carl E. Landwehr University of Minnesota Naval Research Laboratory ABSTRACT Public descriptions of capability-based system designs often do not clarify the necessary details concerning the propagation of access rights within the sys- tems. A casual reader may assume that it is adequate for capabilities to be passed in accordance with the rules for data copying. A system using such a rule cannot enforce either the military security policy or the Bell and LaPadula rules. The paper shows why this problem arises and provides a taxonomy of capability-based designs. Within the space of design options de®ned by the tax- onomy we identify a class of designs that cannot enforce the Bell-LaPadula rules and two designs that do allow their enforcement. Index Terms--Access control, capabilities, capability-based architectures, secu- rity policy, *-property, taxonomy. 1. Introduction Capability systems were ®rst described in the literature in the mid-1960's. Their informal descriptions are typically based upon the notion that a capability is equivalent to a ``ticket,'' in the sense that possession of the ticket allows the possessing process access to the object described in the capability, provided that the access mode is compatible with the ``access rights'' stored within the capability. Several systems using the capability concept have been marketed (IBM System 38, CAP, i432, Plessey S250) [1]. Whether a computer system based upon capabilities can provably enforce the DoD security policy [2] has been a matter of discussion for some time. Boebert [3] has argued that an ``unmodi®ed'' capability machine must be incapable of enforcing the *-property de®ned by Bell and LaPadula [4]. -
Introduction to Programming
Secure Architecture Principles • Isolation and Least Privilege • Access Control Concepts • Operating Systems • Browser Isolation and Least Privilege Original slides were created by Prof. John Mitchel and Suman Janna Some slides are from Prof. David Mazieres 1 Secure Architecture Principles Isolation and Least Privilege 3 Principles of Secure Design • Compartmentalization – Isolation – Principle of least privilege • Defense in depth – Use more than one security mechanism – Secure the weakest link – Fail securely • Keep it simple 4 Principle of Least Privilege • What’s a privilege? – Ability to access or modify a resource • Assume compartmentalization and isolation – Separate the system into isolated compartments – Limit interaction between compartments • Principle of Least Privilege – A system module should only have the minimal privileges needed for its intended purposes 5 Monolithic design Network Network User input System User device File system File system 6 Monolithic design Network Network User input System User device File system File system 7 Monolithic design Network Network User input System User display File system File system 8 Component design Network Network User input User display File system File system 9 Component design Network Network User input User device File system File system 10 Component design Network Network User input User device File system File system 11 Principle of Least Privilege • What’s a privilege? – Ability to access or modify a resource • Assume compartmentalization and isolation – Separate the system -
Capability Based Systems
Capability Based Systems Chester Rebeiro IIT Madras hps://homes.cs.washington.edu/~levy/capabook/Chapter1.pdf 1 Confused Deputy Problem • A computer program that is fooled into misusing authority leading to a privilege escalaon • Fortran Compiler Installed in a directory say SYSX • Writes billing to a file called SYSX/BILL • Writes stasHcs to a file called SYSX/STATS • The SYSX directory is privileged and cannot be wri8en into by other programs (only the compiler can write into it because it had a LISENCE file) • Usage of the Fortran compiler will look like this: SYSX/FORT file_to_be_compiled output_file MISUSE BY USER • SYSX/FORT file_to_be_compiled SYSX/BILL Bill file is overwrien hp://people.csail.mit.edu/alinush/6.858-fall-2014/papers/confused-deputy.pdf 2 Confused Deputy Problem • Who is to blame? • Compiler? • Should the compiler check if for the directory / output file name and prevent access to it? (No, the name SYSX was not invented at the Hme of wriHng the code; BILL is not the only sensiHve file in SYSX) FIXING THE PROBLEM – SWITCH HATS • The compiler wears two hats One hat when sensiHve informaon like the file BILL was wri8en into Other hat was based on user’s privileges to write user file (However this approach cannot be easily generalized – a program may require mulHple hats) hp://people.csail.mit.edu/alinush/6.858-fall-2014/papers/confused-deputy.pdf 3 DiscreHonary Access Control • By Butler Lampson, 1971 (Earliest Form) • Subjects : acHve elements requesHng informaon • Objects : passive elements storing informaon objects – Subjects can also be objects subjects rights Other acHons : ownership (property of objects by a subject), control (father-children relaonships between processes) Butler Lampson, “ProtecHon”, 1971 4 Unix Processes Every procedure called by a program executes within the address space defined by the process. -
Language-Based Security
Language-Based Security Scribe: Sam Kumar In this lecture, we discuss the design of programming languages as it relates to security, and in particular to access control. To motivate this discussion, we begin by reviewing traditional approaches to access control. 1 Motivation for Language-Based Security Access-control lists (ACLs) are a traditional way to enforce permissions for access control. A trusted entity (e.g., operating system) knows which principals (e.g., users, programs) have access to which resources (e.g., files). One problem with ACLs is that they do not keep track of why each principal was granted a certain set of permissions. This allows a malicious entity to misuse permissions, i.e., use permissions for purposes other than those for which they were intended. For example, consider the following scenario. The owner of a server o↵ers the server as a computation resource to many users. The system has a compiler installed, and the owner of the system wants to bill users according to how much they are using the compiler. To this end, the compiler appends an entry to a log file, /var/billing.log, every time a user compiles a file. At the end of every month, the owner of the system bills users according to the entries in /var/billing.log. To protect against malicious users, the system owner does not give users direct access to /var/billing.log. Instead, the system owner gives the compiler program, cc, permission to open and write to /var/billing.log. The idea is that users can only open the file /var/billing.log through the compiler—which is trusted to only modify the file in a correct way. -
Capability-Based Computer Systems Capability-Based Computer Systems
Capability-Based Computer Systems Capability-Based Computer Systems Henry M. Levy BBmoBc1” DIGITAL PRESS Copyright 0 1984 Digital Equipment Corporation All rights reserved. Reproduction of this book, in part or in whole, is strictly prohibited. For copy information contact: Digital Press, 12 Crosby Dr., Bedford, Mass. 01730 Printed in the United States of America 10987654321 Documentation Number: EY-00025-DP ISBN: O-932376-22-3 Library of CongressCataloging in Publication Data Levy, Henry M., 1952- Capability-based computer systems. Bibliography: p. 205 Includes index. 1. Computer architecture. 2. Operating systems (Com- puters) 3. System design. I. Title. QA76.9.A73L48 1983 621.3819’58 83-21029 ISBN O-932376-22-3 Trademarks Bell Laboratories: UNIX. Burroughs Corporation: B5000. Cam- bridge University: CAP. Control Data Corporation: CDC 6400, SCOPE. Digital Equipment Corporation: DEC, LSI-11, PDP-1, PDP-11, TOPS-20. Hewlett-Packard Company: HP 3000. Intel Cor- poration: iAPX 432, iMAX, Intel 8086. IBM: CPF, IBM 370, IBM Systemi38, SWARD. International Computers Ltd.: Basic Language Machine. Plessey Telecommunications Ltd. Plessey System 250. Xerox Corporation: Smalltalk. In Memory of Manny and Sonia Preface The purpose of this book is to provide a single source of infor- mation about capability-based computer systems. Although capability systems have existed for nearly two decades, only recently have they appeared in architecture and operating sys- tem textbooks. Much has been written about capability sys- tems in the technical literature, but finding this information is often difficult. This book is an introduction, a survey, a history, and an evaluation of capability- and object-based computer systems. -
Arxiv:1904.12226V1 [Cs.NI] 27 Apr 2019
The Ideal Versus the Real: Revisiting the History of Virtual Machines and Containers Allison Randal, University of Cambridge Abstract also have greater access to the host’s privileged software (kernel, operating system) than a physically distinct ma- The common perception in both academic literature and chine would have. the industry today is that virtual machines offer better se- curity, while containers offer better performance. How- Ideally, multitenant environments would offer strong ever, a detailed review of the history of these technolo- isolation of the guest from the host, and between guests gies and the current threats they face reveals a different on the same host, but reality falls short of the ideal. The story. This survey covers key developments in the evo- approaches that various implementations have taken to lution of virtual machines and containers from the 1950s isolating guests have different strengths and weaknesses. to today, with an emphasis on countering modern misper- For example, containers share a kernel with the host, ceptions with accurate historical details and providing a while virtual machines may run as a process in the host solid foundation for ongoing research into the future of operating system or a module in the host kernel, so they secure isolation for multitenant infrastructures, such as expose different attack surfaces through different code cloud and container deployments. paths in the host operating system. Fundamentally, how- ever, all existing implementations of virtual machines and containers