DOCSLIB.ORG

Code-Centric Domain Isolation: a Hardware/Software Co-Design for Efficient Program Isolation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Code-Centric Domain Isolation: a Hardware/Software Co-Design for Efficient Program Isolation Code-Centric Domain Isolation: A Hardware/Software Co-Design for Efficient Program Isolation Llu´ıs Vilanova <[email protected]> Barcelona, 2015 ADVISORS: Nacho Navarro Universitat Politecnica` de Catalunya Barcelona Supercomputing Center Yoav Etsion Technion — Israel Institute of Technology Technion Computer Engineering Center A thesis submitted in fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY /DOCTOR PER LA UPC International Doctorate Mention Departament d’Arquitectura de Computadors Universitat Politecnica` de Catalunya Thanks to all the lights along the journey, without whom it would be too dark to travel. Abstract Current Operating Systems (OSs) employ a process-centric isolation model. This is partly attributed to existing processors providing memory isolation across page tables. In this prevailing model, threads are bound to their creating process, and invoking functionality across processes requires costly OS kernel medi- ation and application developer involvement to synchronize and exchange information through Inter-Process Communication (IPC) channels. Therefore, using processes as an isolation unit imposes performance and programmability overheads. Nonetheless, processes also serve two other necessary roles. First, they act as resource containers; OSs track resources like memory and open files at the process granularity. Second, pro- cesses provide in-memory persistence; using a process ensures that its state is consistent across the coming and going of other processes that communicate with it. The architectural foundations used for building pro- cesses impose performance overheads in the excess of 10 and 1000 compared to a function call; that is, privilege level and page table switches, respectively. Even× more, part× of these overheads are not attributable to the hardware itself, but to the inherent overheads imposed by current OS designs. This thesis proposes a hardware and software co-design to eliminate the overheads of process isolation, while providing a path for gradual adoption for more aggressive optimizations. On the hardware side, this thesis proposes the CODOMs protection architecture. It provides memory and privilege protection across software components in a way that is at the same time very efficient and very flexible. This hardware substrate is then used to propose DomOS, which provides changes to the OS at the runtime and kernel layers to allow threads to efficiently and securely cross process boundaries using regular function calls. That is, a thread in one process is allowed to call into a function residing in another process without involving the OS in the critical communication path. This is achieved by mapping processes into a shared address space and eliminating IPC overheads through a combination of new hardware primitives and compile-time and run-time optimizations. IPC in DomOS is up to 24 times faster than Linux pipes, and up to 14 times faster than IPC in L4 Fiasco.OC. When applied to a multi-tier× web server, DomOS performs up to 2.18× better than an unmodified Linux system, and 1.32 on average. On all configurations, DomOS provides more× than 85% of the ideal system efficiency. × i Contents 1 Introduction 1 1.1 The Granularity, Performance and Programmability Dilemma.................1 1.2 Conjoining Isolation, Performance and Programmability...................2 1.3 Document Organization.....................................4 2 A Comparison of Related System Organizations and Isolation Primitives7 2.1 A Note on Nomenclature....................................7 2.2 Hardware Protection Mechanisms...............................7 2.2.1 Privilege Levels.....................................8 2.2.2 Address Spaces.....................................9 2.2.3 Machine Virtualization................................. 11 2.2.4 Capability Architectures................................ 12 2.3 Operating System Organization Models............................ 16 2.4 Software Isolation Mechanisms................................. 17 2.4.1 Processes........................................ 17 2.4.2 Address Spaces..................................... 17 2.4.3 Machine Virtualization................................. 18 2.4.4 Software Fault Isolation................................ 18 3 The Interplay Between Isolation and System Design 19 3.1 The Inadequacies of Process-Based Isolation.......................... 19 3.2 Mismatch Between Procedure Call and IPC Semantics.................... 23 3.3 False Concurrency....................................... 25 3.4 A Case for Configurable Isolation Policies........................... 26 4 Efficient and Composable Isolation Primitives 27 4.1 Security Model......................................... 28 4.1.1 Asymmetric Isolation Policies............................. 28 4.2 System Design Overview.................................... 29 4.2.1 CODOMs........................................ 30 4.2.2 Compiler Support.................................... 33 4.2.3 DomOS......................................... 33 4.3 Isolation Scenarios....................................... 34 iii 5 Hardware Support 37 5.1 Code-Centric Protection.................................... 37 5.1.1 Page Table Capabilities................................. 37 5.1.2 Domain Access Permissions.............................. 40 5.1.3 Access Protection List................................. 41 5.1.4 Example of Code-Centric Protection.......................... 41 5.2 Capability Protection...................................... 42 5.2.1 Example of Capability Protection........................... 44 5.2.2 Capability Confidentiality............................... 45 5.2.3 Capability Unforgeability and Integrity........................ 45 5.2.4 Domain Capability Stack................................ 45 5.2.5 Capability Revocation................................. 46 5.3 Enforcing Domain Entry and Exit Points............................ 47 5.4 Implementation of Access Protection Checks......................... 48 5.5 Efficient Execution in Out-of-Order Pipelines......................... 50 5.6 Revisiting Isolation Scenarios................................. 50 6 Compiler Support 53 6.1 Language Interface....................................... 53 6.2 Implementation......................................... 55 6.3 Example............................................. 56 7 Operating System Support 59 7.1 Processes and Threads..................................... 60 7.2 Low-Level Isolation Interface.................................. 61 7.2.1 Domain Management.................................. 61 7.2.2 Entry Point and Cross-Domain Proxy Management.................. 61 7.2.3 Capability Management................................ 64 7.3 Runtime Support........................................ 65 7.3.1 Program Loading.................................... 65 7.3.2 Entry Point Resolution................................. 66 7.4 Implementation Details..................................... 67 7.4.1 Unified Virtual Address Space............................. 67 7.4.2 Thread Management.................................. 68 7.4.3 Thread-Local Storage.................................. 68 7.4.4 Cross-Process Proxies................................. 69 7.4.5 Fault Notification.................................... 69 7.5 Capabilities as Opaque Handles to User-Defined Objects................... 69 7.6 Unified Resource Access Controls............................... 70 8 Evaluation 71 8.1 Hardware Mechanisms (CODOMs).............................. 71 8.1.1 Comparison of Different Cross-Domain Call Mechanisms.............. 71 8.1.2 Effect of Isolation Policies............................... 74 8.1.3 Area and Energy Overheads.............................. 75 8.1.4 Linux Kernel Module Isolation............................. 76 8.2 System Performance (DomOS)................................. 77 8.2.1 Comparison of Different Domain Communication Primitives............. 78 8.2.2 Thread Isolation.................................... 81 8.2.3 High-Performance Device Driver Isolation...................... 83 8.2.4 Multi-Tier Web Server Isolation............................ 84 9 Conclusions 87 A FlowTAS: Making Data-Centric Mandatory Access Control Practical 89 A.1 Introduction........................................... 89 A.2 Motivation............................................ 93 A.2.1 Example Setting and Privacy Expectations....................... 93 A.2.2 Data Leaks with Untrusted Applications........................ 93 A.2.3 Plugging Untrusted-Application Data Leaks...................... 93 A.2.4 Limitations of Prior MAC systems........................... 94 A.2.5 Problem Definition................................... 96 A.2.6 FlowTAS Overview................................... 97 A.3 Design of the FlowTAS System................................. 98 A.3.1 Trusted User Interface................................. 98 A.3.2 Web Proxy....................................... 98 A.3.3 Container Manager................................... 99 A.3.4 Template Processor................................... 99 A.3.5 Storage Declassifier.................................. 100 A.4 FlowTAS Implementation.................................... 100 A.4.1 Object Categories for Data-Centric MAC....................... 100 A.4.2 Web Proxy and Container Manager.......................... 102 A.4.3 Container and Application Instance Management................... 102 A.4.4 Template Processor................................... 104 A.5 Security Properties......................................
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]
  • Capabilities
    CS 261, Fall 2015 Scribe notes September 8: Capabilities Scribe: Riyaz Faizullabhoy 1 Motivation for Capabilities In The Confused Deputy, the compiler had two sets of rights: one from the user to access user files such as source code to compile, and another set granted to the compiler intended to access a special statistics file that would collect information about language feature usage. The compiler was installed in the SYSX directory, where it was granted access to write to any file in this directory. Naturally, the statistics file SYSX/STAT was also located in this directory such that the compiler (SYSX/FORT) could add language feature information. To achieve this, the compiler's privileges were set with a home files license that was allowed by the operating system to write to any file in the SYSX directory. A billing information file SYSX/BILL was also stored in SYSX { due to its sensitive nature, this billing file was not directly accessible to users. However, since the compiler was granted access to the entire SYSX directory, users could subvert their access restrictions on the billing information file by using the compiler like so: SYSX/FORT foo.f -o SYSX/BILL The above user-invoked command to the compiler would allow the compiler to first read the user's source code in foo.f, but then the compiler's privilege to SYSX would cause the SYSX/BILL file to be overwritten with the user's binary. In effect, the compiler is the confused deputy having to reconcile both its own and the user's set of privileges, but unfortunately allows for unintended behavior.
    [Show full text]
  • Operating Systems & Virtualisation Security Knowledge Area
    Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 Herbert Bos Vrije Universiteit Amsterdam EDITOR Andrew Martin Oxford University REVIEWERS Chris Dalton Hewlett Packard David Lie University of Toronto Gernot Heiser University of New South Wales Mathias Payer École Polytechnique Fédérale de Lausanne The Cyber Security Body Of Knowledge www.cybok.org COPYRIGHT © Crown Copyright, The National Cyber Security Centre 2019. This information is licensed under the Open Government Licence v3.0. To view this licence, visit: http://www.nationalarchives.gov.uk/doc/open-government-licence/ When you use this information under the Open Government Licence, you should include the following attribution: CyBOK © Crown Copyright, The National Cyber Security Centre 2018, li- censed under the Open Government Licence: http://www.nationalarchives.gov.uk/doc/open- government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at con- [email protected] to let the project know how they are using CyBOK. Issue 1.0 is a stable public release of the Operating Systems & Virtualisation Security Knowl- edge Area. However, it should be noted that a fully-collated CyBOK document which includes all of the Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas KA Operating Systems & Virtualisation Security j October 2019 Page 1 The Cyber Security Body Of Knowledge www.cybok.org INTRODUCTION In this Knowledge Area, we introduce the principles, primitives and practices for ensuring se- curity at the operating system and hypervisor levels.
    [Show full text]
  • A Capability-Based Module System for Authority Control∗†
    A Capability-Based Module System for Authority Control∗† Darya Melicher1, Yangqingwei Shi2, Alex Potanin3, and Jonathan Aldrich4 1 Carnegie Mellon University, Pittsburgh, PA, USA 2 Carnegie Mellon University, Pittsburgh, PA, USA 3 Victoria University of Wellington, Wellington, New Zealand 4 Carnegie Mellon University, Pittsburgh, PA, USA Abstract The principle of least authority states that each component of the system should be given author- ity to access only the information and resources that it needs for its operation. This principle is fundamental to the secure design of software systems, as it helps to limit an application’s attack surface and to isolate vulnerabilities and faults. Unfortunately, current programming languages do not provide adequate help in controlling the authority of application modules, an issue that is particularly acute in the case of untrusted third-party extensions. In this paper, we present a language design that facilitates controlling the authority granted to each application module. The key technical novelty of our approach is that modules are first- class, statically typed capabilities. First-class modules are essentially objects, and so we formalize our module system by translation into an object calculus and prove that the core calculus is type- safe and authority-safe. Unlike prior formalizations, our work defines authority non-transitively, allowing engineers to reason about software designs that use wrappers to provide an attenuated version of a more powerful capability. Our approach allows developers to determine a module’s authority by examining the capab- ilities passed as module arguments when the module is created, or delegated to the module later during execution.
    [Show full text]
  • Runtime Data Driven Partitioning of Linux Code
    This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TDSC.2017.2745574 1 How to Fillet a Penguin: Runtime Data Driven Partitioning of Linux Code Oliver Schwahn, Stefan Winter, Nicolas Coppik, and Neeraj Suri Abstract—In many modern operating systems (OSs), there exists no isolation between different kernel components, i.e., the failure of one component can affect the whole kernel. While microkernel OSs introduce address space separation for large parts of the OS, their improved fault isolation comes at the cost of performance. Despite significant improvements in modern microkernels, monolithic OSs like Linux are still prevalent in many systems. To achieve fault isolation in addition to high performance and code reuse in these systems, approaches to move only fractions of kernel code into user mode have been proposed. These approaches solely rely on static code analyses for deciding which code to isolate, neglecting dynamic properties like invocation frequencies. We propose to augment static code analyses with runtime data to achieve better estimates of dynamic properties for common case operation. We assess the impact of runtime data on the decision what code to isolate and the impact of that decision on the performance of such “microkernelized” systems. We extend an existing tool chain to implement automated code partitioning for existing monolithic kernel code and validate our approach in a case study of two widely used Linux device drivers and a file system.
    [Show full text]
  • Capsicum Slides
    Capsicum Capability-Based Sandboxing David Drysdale Google UK Features Current LXC uses the following kernel features to contain processes: ● Kernel namespaces (ipc, uts, mount, pid, network and user) ● Apparmor and SELinux profiles ● Seccomp policies ● Chroots (using pivot_root) ● Kernel capabilities ● CGroups (control groups) Agenda ● Ideas ○ Privilege Separation ○ Capabilities ● Capsicum ○ Hybrid with POSIX ○ Application changes ● Linux container features ● Status/Outlook Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way ● Divide up software according to what privileges are needed ○ E.g. separate media processing from credentials processing Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way ● Divide up software according to what privileges are needed ○ E.g. separate media processing from credentials processing ● Examples: ○ OpenSSH: credential checking process ○ Chrome: renderer processes ● Design impact: ○ Do privileged operations first ○ Pass resources down a privilege gradient Capability-Based Security ● Make the privileges that a process holds more explicit Capability-Based Security ● Make the privileges that a process holds more explicit ● Access objects via unforgeable token: the capability ○ Identifies the object ○ Accompanying rights give allowed operations ○ Can only reduce, not increase rights ○ Can pass capabilities around Capability-Based Security ● Make the privileges that a process holds more explicit ● Access objects via unforgeable token: the capability ○ Identifies the object ○ Accompanying rights give allowed operations ○ Can only reduce, not increase rights ○ Can pass capabilities around ● Remove other ways of accessing objects ○ No access by name, i.e.
    [Show full text]
  • 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.
    [Show full text]
  • Semperos: a Distributed Capability System
    SemperOS: A Distributed Capability System Matthias Hille† Nils Asmussen† ∗ Pramod Bhatotia‡ Hermann Härtig† ∗ †Technische Universität Dresden ‡The University of Edinburgh ∗ Barkhausen Institut Abstract systems have received renewed attention recently to provide Capabilities provide an efficient and secure mechanism for an efficient and secure mechanism for resource management fine-grained resource management and protection. However, in modern hardware architectures [5, 24, 30, 36, 44, 64, 67]. as the modern hardware architectures continue to evolve Today the main improvements in compute capacity with large numbers of non-coherent and heterogeneous cores, are achieved by either adding more cores or integrating we focus on the following research question: can capability accelerators into the system. However, the increasing core systems scale to modern hardware architectures? counts exacerbate the hardware complexity required for global In this work, we present a scalable capability system to drive cache coherence. While on-chip cache coherence is likely to future systems with many non-coherent heterogeneous cores. remain a feature of future hardware architectures [45], we see More specifically, we have designed a distributed capability characteristics of distributed systems added to the hardware system based on a HW/SW co-designed capability system. by giving up on global cache coherence across a whole We analyzed the pitfalls of distributed capability operations machine [6, 28]. Additionally, various kinds of accelerators running concurrently and built the protocols in accordance are added like the Xeon Phi Processor, the Matrix-2000 accel- with the insights. We have incorporated these distributed erator, GPUs, FPGAs, or ASICs, which are used in numerous capability management protocols in a new microkernel-based application fields [4,21,32,34,43,60].
    [Show full text]
  • Embassies: Radically Refactoring the Web Jon Howell, Bryan Parno, John R
    Embassies: Radically Refactoring the Web Jon Howell, Bryan Parno, John R. Douceur, Microsoft Research Abstract of evolving complexity. On the Internet, application Web browsers ostensibly provide strong isolation for providers, or vendors, run server-side applications over the client-side components of web applications. Unfor- which they exercise total control, from the app down tunately, this isolation is weak in practice; as browsers to the network stack, firewall, and OS. Even when ven- add increasingly rich APIs to please developers, these dors are tenants of a shared datacenter, each tenant au- complex interfaces bloat the trusted computing base and tonomously controls its software stack down to the ma- erode cross-app isolation boundaries. chine code, and each tenant is accessible only via IP. We reenvision the web interface based on the notion The strong isolation among virtualized Infrastructure-as- of a pico-datacenter, the client-side version of a shared a-Service datacenter tenants derives not from physical server datacenter. Mutually untrusting vendors run their separation but from the execution interface’s simplicity. code on the user’s computer in low-level native code con- This paper extends the semantics of datacenter rela- tainers that communicate with the outside world only via tionships to the client’s web experience. Suspending dis- IP. Just as in the cloud datacenter, the simple semantics belief momentarily, suppose every client had ubiquitous makes isolation tractable, yet native code gives vendors high-performance Internet connectivity. In such a world, the freedom to run any software stack. Since the datacen- exploiting datacenter semantics is easy: The client is ter model is designed to be robust to malicious tenants, it merely a screencast (VNC) viewer; every app runs on is never dangerous for the user to click a link and invite its vendor’s servers and streams a video of its display to a possibly-hostile party onto the client.
    [Show full text]
  • Improvement of the Virtualization Support in the Fiasco.OC Microkernel
    Technische Universität Berlin Master’s Thesis Chair for Security in Telecommunications (SecT) School IV — Electrical Engineering and Computer Science Technische Universität Berlin Improving Virtualization Support in the Fiasco.OC Microkernel Author: Julius Werner (#310341) Major: Computer Science (Informatik) Email: [email protected] Primary Advisor: Prof. Dr. Jean-Pierre Seifert Secondary Advisor: Prof. Dr. Hans-Ulrich Heiß Tutor: Dipl.-Inf. Matthias Lange April – August 2012 Abstract This thesis aims to improve the memory virtualization efficiency of the Fiasco.OC mi- crokernel on processors with the Intel VMX hardware-assisted virtualization architecture, which is plagued by severe performance degradation. After discussing possible approaches, this goal is accomplished by implementing support for Intel’s nested paging mechanism (EPT). Fiasco.OC’s memory management system is enhanced to allow a new kind of task whose address space is stored in the EPT page attribute format while staying compati- ble with the existing shared memory mapping interface through dynamic page attribute translation. This enhancement is complemented with support for tagged TLB entries (VPIDs), independently providing another minor performance increase. The kernel’s external virtualization API and the experimental userland VMM Karma are adapted to support these changes. The final implementation is evaluated and analyzed in the context of several benchmarks, achieving near-native performance on real-world workloads while only constituting a minor increase in complexity for the microkernel. Zusammenfassung Diese Arbeit zielt darauf ab die Speichervirtualisierungseffizienz des Fiasco.OC Mikro- kerns auf Prozessoren mit der hardwareunterstützten Virtualisierungsarchitektur Intel VMX zu verbessern, welche von schweren Performanzverlusten geplagt wird. Nach der Diskussion möglicher Lösungsansätze wird dieses Ziel mit der Unterstützung von Intels Mechanismus für verschachtelte Seitentabellen (EPT) umgesetzt.
    [Show full text]
  • SHILL: a Secure Shell Scripting Language
    SHILL: A Secure Shell Scripting Language Scott Moore, Christos Dimoulas, Dan King, and Stephen Chong Harvard School of Engineering and Applied Sciences Abstract require significant changes to existing software, and are The Principle of Least Privilege suggests that software often not available to all users [16]. For both of these rea- should be executed with no more authority than it re- sons, users tend to execute software with more authority quires to accomplish its task. Current security tools make than is necessary. it difficult to apply this principle: they either require sig- For example, consider scripts to grade homework sub- nificant modifications to applications or do not facilitate missions in a computer science course. Students submit reasoning about combining untrustworthy components. source code, and a script grade.sh is run on each sub- We propose SHILL, a secure shell scripting language. mission to compile it and run it against a test suite. The SHILL scripts enable compositional reasoning about se- submission server must execute grade.sh with suffi- curity through contracts that limit the effects of script cient authority to accomplish its task, but should also execution, including the effects of programs invoked by restrict its authority to protect the server from student- the script. SHILL contracts are declarative security poli- submitted code and ensure the integrity of grading. At a cies that act as documentation for consumers of SHILL coarse grain, the server should allow grade.sh to ac- scripts, and are enforced through a combination of lan- cess files and directories necessary to compile, run, and guage design and sandboxing.
    [Show full text]
  • Capsicum on Linux
    Capsicum on Linux David Drysdale 18 Aug 2014 Linux Security Summit Capsicum ● Pragmatic application ● of object-capability principles ● to UNIX ● and Linux in particular Google Confidential and Proprietary Capability-Based Security ● All object access needs a token: the capability ○ identifies the object ○ accompanying rights give allowed operations Google Confidential and Proprietary Capability-Based Security ● All object access needs a token: the capability ○ identifies the object ○ accompanying rights give allowed operations ● Avoid object naming & ambient authority ○ Prevent confused deputy attacks ○ Acquire capabilities ■ by inheritance ■ by creation (with subset of rights) ■ by passing Google Confidential and Proprietary Capability-Based Security ● All object access needs a token: the capability ○ identifies the object ○ accompanying rights give allowed operations ● Avoid object naming & ambient authority ○ Prevent confused deputy attacks ○ Acquire capabilities ■ by inheritance ■ by creation (with subset of rights) ■ by passing ● Note: completely different than POSIX.1e capabilities Google Confidential and Proprietary Capsicum Principles ● POSIX File Descriptor Behaviour Google Confidential and Proprietary Capsicum Principles ● POSIX File Descriptor Behaviour ● Hence Capsicum: ○ file descriptors as capabilities ○ with (new) fine-grained rights ■ policy co-located with code (ENOTCAPABLE) Google Confidential and Proprietary Capsicum Principles ● POSIX File Descriptor Behaviour ● Hence Capsicum: ○ file descriptors as capabilities ○
    [Show full text]