DOCSLIB.ORG

Security in Keykos

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Security in Keykos SECURITY IN KEYKOS S.A. RAJUNAS, N. HARDY, A.C. BOMBERGER, W.S. FRANTZ, C.R. LANDAU K.@A@, Cupertino, California ABSTRACT KeyKOS is a message-passing system. KeyKOS is also an object-oriented system, where certain primitive KeyKOSTM** is a capability-based system which was objects are supported by the kernel and application designed to meet the performance, reliability, and designers can build their own objects out of security goals of the commercial computer service system-defined objects. These user-defined objects marketplace, KeyKOSs architecture combines are much larger than Smalltalk4 objects. several unique features to achieve simple and effective protection mechanisms with a very small Like all capability systems, KeyKOS must prevent the amount of privileged code. Particular emphasis is forging of capabilities. This is accomplished not by placed here on the protection mechanisms which relying on tagged memory but rather by storing support security; while some general description of the capabilities separate from data. system is included, a.more com Iete description of the architecture is given elsewhere ? Capabilities in KeyKOS are called keys, and the reader may substitute “capability” anywhere the term “key” is used. However, in KeyKOS there are many KeyKOS consists of a kernel and supplementary code. different types of keys (see Table 1). Keys carry The KeyKOS kernel is currently implemented in several different types of authority, not merely software, but in concept it is an extension of the read-only and read/write, and designate objects of all machine architecture and as such could be types. implemented in firmware and/or hardware. The present implementation runs on IBM and Amdahl Some of the terminology used in KeyKOS is unique, hardware. Any virtualizable architecture with a large and the unfamiliar terms have been cited as a source virtual address space and demand paging would be a of confusion by individuals first learning about the suitable target. KeyKOS might also be ported to other system. There have been suggestions that we should architectures. use “more standard terminology,” but each system uses its own terminology. Capabilities are “access KeyKOS is not a traditional operating system; it bears descriptors” in the Intel 4325, and “pointers” in some resemblance to a control program (it manages System/386. (See Levy7 for a survey of implemented resources). In the current implementation, the kernel capability systems). It has also been suggested that is written in assembler, is unswappable, and runs in we use the terminology popularized by, say, Hydra8, supervisor mode with real addresses. The kernel and certainly the most published system. But KeyKOS is supplementary code present a different architecture to not a copy of Hydra. KeyKOS has different basic the programmer from that provided by the bare design concepts, described by different terms; the hardware. KeyKOS supports CMS3, and currently terms are different because the concepts are different. most software development is done using CMS as the development environment. KeyKOS provides an The convention used in this paper is that KeyKOS excellent run time environment for transaction-based terms are printed in bold type when they are first applications, and KeyKOS has been running in defined. support of commercial applications since 1983. The basic entities in KeyKOS are keys, pages, and nodes. Keys are capabilities, and designate pages, ●’ PatentPending. nodes, other primitive objects implemented by the 78 CH2292-1/86/0000/0078$01.0001986 IEEE kernel, or compound constructs made up of pages and In KeyKOS terminology, keys in the domain’s root nodes. Pages consist of 4096 bytes, may contain node are said to be elements of the domain. Keys in code or data, but cannot contain keys. Pages may be the keys node are said to be held by the domain, and regarded as permanent storage; KeyKOS implements their use is determined entirely by the program a single level store. A node consists of 16 slots (may obeyed by the domain. In fact, a program in a domain be thought of as capability registers), which contain does not actually handle any keys (it can only address keys, but not code or data. Nodes are also permanent the contents of pages); it refers to the keys it holds by storage. their slot numbers in the keys node and the kernel ,inteqxets the requests for access. The three fundamental objects in KeyKOS are domains, meters, and segments. Domains are Meters are nodes which represent resources that may roughly analogous to processes, meters represent be consumed by a domain. As a domain uses CPU resources (such as CPU time), and segments define time (currently the only metered resource) the meter ranges of virtual addresses. counts down. When it reaches zero, the domain stops, but no information is destroyed and the domain may A domain is a fundamental object which obeys some be restarted by adding more resources. There is a code (program) and holds some keys that the code primordial meter from which aii meters are descended, can reference. It is important to note that “process” is and in the hierarchy of meters, meters lower in the tree not a technical term in KeyKOS. While someone new (inferior) depend on meters higher in the tree to KeyKOS may analyze a KeyKOS scenario by (superior), so any use of CPU time is measured and envisioning processes, there are no such entities in constrained not oniy by the immediate meter but also the implementation. The closest concept to ‘process” by its superiors. in KeyKOS is the domain. We include what is commonly meant by “process”, along with address KeyKOS uses the concept of the single-level store. space and access rights, in the concept of domain. A No user written code needs any concept of secondary domain is not just a privilege state, as it is in some storage. Also, ali access to data is immediate. A systems. In KeyKOS one cannot speak of a process domain’s address space is implemented by a segment moving from domain to domain; the closest analogy is key; a segment consists of other segments or pages. a thread of control passing from one domain to One domain cannot access data in another domain -- another. it can only access data on pages in its own address space. Pages can be shared, and even shared with Programmers may create their own objects from one different authority, but only if prearranged. Either the or more domains. Each domain contains algorithms, domains’ address spaces must have been built with data, state information, and access rights. In the shared pages or the domains were set up to be able to current implementation, a domain is three nodes (the exchange page keys and insert them in their address root node, the registers node, and the keys node), and spaces. the keys found in the slots of the root node have special interpretations (see KeyKOS Principles of Because of the single-level store, KeyKOS has no Operationg for details). The slots in the root node “files,” but domains serve a similar roie. Domains are contain keys which designate the domain’s address as long-lived as files in traditional systems; they segment, the domain’s keeper and its meter continue to exist until deliberately deleted. Record (described below), status information (domains may collections are domains which perform the be available, running, or waiting), most of the specialized function of relating symbolic names to PSW, etc. The registers node contains the general keys. Some record collections function as directories; purpose registers and the floating point registers. The others serve to emulate the functionality of IBM file keys node contains keys accessible to the program in access methods. the domain. The keys in the domain’s root node in general are not accessible to the program the domain obeys, any more than a process header or task control Key lnvocati~ block is accessible to the processor task in a conventional operating system. They are data The basic operation in KeyKOS is key invocation. structures maintained on behalf of the domain or There are three ways to invoke a key: FORK, CALL, process or task by the operating system. The and RETURN (the traditional meanings apply). difference is that in KeyKOS, the domain couldbe Control is passed either to the kernei (if it was a key given a key to any root node (including its own), and it the kernei implements) or to another domain via the could affect only that node for which it had a key. In a kernel (if it was a gate key). The KeyKOS equivalent conventional system, the program would have to be to interprocess communication is a gate key privileged to access its own process header and it invocation between domains which passes a would have not merely that privilege but all privileges message consisting of up to four keys, a byte string, (the pervasive privilege problem). and a parameter word. 79 The key invocation mechanism unifies message implicitly invoked when the resource counter aoes to passing and procedure call functionality. An argument zero. The segment keeper is implicitly invok~d on has been madel 0 that operating systems fail into memory faults. Memory faults occur on encountering either the message passing categoty (characterized invalid addresses and write protection violation, not by a small, static number of processes with explicit page faults(which are handled by the kernel). The communication paths) or the procedure call category segment keeper receives, when CALLed, a node key (characterized by a large, rapidly changing number of to the segment so it can fetch from and store into slots small processes with process synchronization based containing memory keys (segment or page keys). The on shared data) and that these categories are duals of kernel builds a domain’s page tables based on the each other.
Load more

Recommended publications
  • Automatic Sandboxing of Unsafe Software Components in High Level Languages
    Master Thesis Automatic Sandboxing of Unsafe Software Components in High Level Languages Benjamin Lamowski Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Professur Betriebssysteme Betreuender Hochschullehrer: Prof. Dr. rer. nat. Hermann Härtig Betreuender Mitarbeiter: Dr. Carsten Weinhold 3. Mai 2017 Aufgabenstellung Neue “sichere“ Programmiersprachen wie Go, Swift oder Rust wurden nicht nur für die normale Anwendungsentwicklung entworfen, sondern sie zielen auch auf eine hochper- formante Ausführung und Programmierung vergleichsweise systemnaher Funktionalität ab. Eine attraktive Eigenschaft beispielsweise von Rust ist das gegenüber C und C++ deutlich strengere Speicherverwaltungsmodell, bei dem bereits zur Kompilierzeit der Lebenszyklus und die Erreichbarkeit von Objekten sowie die Zuständigkeit für deren Allokation und Deallokation wohldefiniert sind. Ganze Klassen von Programmfehlern wie etwa Buffer Overflows oder Dereferenzierung ungültige Zeiger werden dadurch eliminiert und die Programme mithin sicherer und robuster. Aus diversen Gründen müssen Programme, die in sicheren Sprachen geschriebenen wurden, aber oftmals auf “unsicheren“ Legacy-Code zurückgreifen. So bietet etwa Rust über das “unsafe“-Sprachelement die Möglichkeit, Funktionen innerhalb von Bibliotheken aufzurufen, die in fehleranfälligem C geschrieben sind. Leider werden die vom Com- piler durchgesetzten Garantien der sicheren Sprache hinfällig, sobald im Code einer C-Bibliothek ein Speicherfehler auftritt. Ein Schreibzugriff etwa durch
    [Show full text]
  • A Microkernel API for Fine-Grained Decomposition
    A Microkernel API for Fine-Grained Decomposition Sebastian Reichelt Jan Stoess Frank Bellosa System Architecture Group, University of Karlsruhe, Germany freichelt,stoess,[email protected] ABSTRACT from the microkernel APIs in existence. The need, for in- Microkernel-based operating systems typically require spe- stance, to explicitly pass messages between servers, or the cial attention to issues that otherwise arise only in dis- need to set up threads and address spaces in every server for tributed systems. The resulting extra code degrades per- parallelism or protection require OS developers to adopt the formance and increases development effort, severely limiting mindset of a distributed-system programmer rather than to decomposition granularity. take advantage of their knowledge on traditional OS design. We present a new microkernel design that enables OS devel- Distributed-system paradigms, though well-understood and opers to decompose systems into very fine-grained servers. suited for physically (and, thus, coarsely) partitioned sys- We avoid the typical obstacles by defining servers as light- tems, present obstacles to the fine-grained decomposition weight, passive objects. We replace complex IPC mecha- required to exploit the benefits of microkernels: First, a nisms by a simple function-call approach, and our passive, lot of development effort must be spent into matching the module-like server model obviates the need to create threads OS structure to the architecture of the selected microkernel, in every server. Server code is compiled into small self- which also hinders porting existing code from monolithic sys- contained files, which can be loaded into the same address tems. Second, the more servers exist | a desired property space (for speed) or different address spaces (for safety).
    [Show full text]
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [Show full text]
  • On the Construction of Reliable Device Drivers Leonid Ryzhyk
    On the Construction of Reliable Device Drivers Leonid Ryzhyk Ph.D. 2009 ii iii ‘I hereby declare that this submission is my own work and to the best of my knowledge it contains no materials previously pub- lished or written by another person, or substantial proportions of material which have been accepted for the award of any other degree or diploma at UNSW or any other educational institution, except where due acknowledgement is made in the thesis. Any contribution made to the research by others, with whom I have worked at UNSW or elsewhere, is explicitly acknowledged in the thesis. I also declare that the intellectual content of this the- sis is the product of my own work, except to the extent that as- sistance from others in the project’s design and conception or in style, presentation, and linguistic expression is acknowledged.’ Signed .................................. Date .................................. iv Abstract This dissertation is dedicated to the problem of device driver reliability. Software defects in device drivers constitute the biggest source of failure in operating systems, causing sig- nificant damage through downtime and data loss. Previous research on driver reliability has concentrated on detecting and mitigating defects in existing drivers using static analysis or runtime isolation. In contrast, this dissertation presents an approach to reducing the number of defects through an improved device driver architecture and development process. In analysing factors that contribute to driver complexity and induce errors, I show that a large proportion of errors are due to two key shortcomings in the device-driver architecture enforced by current operating systems: poorly-defined communication protocols between drivers and the operating system, which confuse developers and lead to protocol violations, and a multithreaded model of computation, which leads to numerous race conditions and deadlocks.
    [Show full text]
  • The Flask Security Architecture: System Support for Diverse Security Policies
    The Flask Security Architecture: System Support for Diverse Security Policies Ray Spencer Secure Computing Corporation Stephen Smalley, Peter Loscocco National Security Agency Mike Hibler, David Andersen, Jay Lepreau University of Utah http://www.cs.utah.edu/flux/flask/ Abstract and even many types of policies [1, 43, 48]. To be gen- erally acceptable, any computer security solution must Operating systems must be flexible in their support be flexible enough to support this wide range of security for security policies, providing sufficient mechanisms for policies. Even in the distributed environments of today, supporting the wide variety of real-world security poli- this policy flexibility must be supported by the security cies. Such flexibility requires controlling the propaga- mechanisms of the operating system [32]. tion of access rights, enforcing fine-grained access rights and supporting the revocation of previously granted ac- Supporting policy flexibility in the operating system is cess rights. Previous systems are lacking in at least one a hard problem that goes beyond just supporting multi- of these areas. In this paper we present an operating ple policies. The system must be capable of supporting system security architecture that solves these problems. fine-grained access controls on low-level objects used to Control over propagation is provided by ensuring that perform higher-level functions controlled by the secu- the security policy is consulted for every security deci- rity policy. Additionally, the system must ensure that sion. This control is achieved without significant perfor- the propagation of access rights is in accordance with mance degradation through the use of a security decision the security policy.
    [Show full text]
  • Microkernels Meet Recursive Virtual Machines
    Microkernels Meet Recursive Virtual Machines Bryan Ford Mike Hibler Jay Lepreau Patrick Tullmann Godmar Back Stephen Clawson Department of Computer Science, University of Utah Salt Lake City, UT 84112 [email protected] http://www.cs.utah.edu/projects/flux/ Abstract ªverticallyº by implementing OS functionalityin stackable virtual machine monitors, each of which exports a virtual Thispaper describes a novel approach to providingmod- machine interface compatible with the machine interface ular and extensible operating system functionality and en- on which it runs. Traditionally,virtual machines have been capsulated environments based on a synthesis of micro- implemented on and export existing hardware architectures kernel and virtual machine concepts. We have developed so they can support ªnaiveº operating systems (see Fig- a software-based virtualizable architecture called Fluke ure 1). For example, the most well-known virtual machine that allows recursive virtual machines (virtual machines system, VM/370 [28, 29], provides virtual memory and se- running on other virtual machines) to be implemented ef- curity between multiple concurrent virtual machines, all ®ciently by a microkernel running on generic hardware. exporting the IBM S/370 hardware architecture. Further- A complete virtual machine interface is provided at each more, special virtualizable hardware architectures [22, 35] level; ef®ciency derives from needing to implement only have been proposed, whose design goal is to allow virtual new functionality at each level. This infrastructure allows machines to be stacked much more ef®ciently. common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to This paper presents a new approach to OS extensibil- be provided by cleanly modularized, independent, stack- ity which combines both microkernel and virtual machine able virtual machine monitors, implemented as user pro- concepts in one system.
    [Show full text]
  • Executive Summary
    Mobile Commerce Security: Legal & Technological Perspectives Michael Triguboff Table of Contents EXECUTIVE SUMMARY 4 INTRODUCTION 7 The Need for Security 11 PART I TECHNOLOGY 12 Client-Side Vulnerabilities 12 Browser Software 13 Java Applets 14 ActiveX controls 16 JavaScript 18 Plug-Ins and Graphic Files 18 Push technology 18 Web Server Security 19 Front-end 20 Firewalls 22 Back-end Database vulnerabilities 23 Server- Side Middleware 24 Operating System Problems 25 Hardened versions of Operating Systems 36 Distributed systems 37 Software Testing 38 Mobile Commerce Issues 43 Device Properties 43 Wireless Communication 45 Wireless Communication Protocols 47 Ad Hoc Networks 49 Ad Hoc Networks and Key Management 51 Network Protection in Ad Hoc Networks 54 Location Dependent Information and Mobile Computing 55 Mobile Agents 56 Protecting the Host from the Mobile Agent 59 Safe Code Interpretation 61 Digital Signatures 63 Proof Carrying Code 63 Path Histories 64 Software-Based Fault Isolation [“Sandboxing”] 64 Protecting the Agent From the Host and Other Agents 64 Secure Control of Remote Agents 65 Read-Only/Append-Only 65 Partial Results Encapsulation 66 Code Obfuscation 67 Computing with Encrypted Functions 67 Environmental Key Generation 68 Execution Tracing 68 Itinerary Recording 69 Security Through Shared Secrets and Interlocking 69 Other Approaches 69 Attacks Based on Device Limitations 71 2 Prevention, Detection and Reaction 71 Intrusion Detection 72 Intrusion Detection and Mobile Agents 75 Part I Conclusion 76 PART 11 THE LEGAL PERSPECTIVE 80 The Debate: A Confluence of Two Streams 81 Uniform Electronic Transactions Act 85 Article 2B of the Uniform Commercial Code 85 The Electronic Signatures in Global and National Commerce Act [“E-Sign Act”] 88 Jurisdiction Selection 90 Reaction- Criminal Law 96 Convention on Cyber-Crime 97 Evidentiary or Procedural Law 99 Practical Considerations 100 Part II Conclusion 101 APPENDIX 103 Digital Millennium Copyright Act 103 BIBLIOGRAPHY 107 3 EXECUTIVE SUMMARY The objectives of this project are twofold.
    [Show full text]
  • All Computer Applications Need to Store and Retrieve Information
    MyFS: An Enhanced File System for MINIX A Dissertation Submitted in partial fulfillment of the requirement for the award of the degree of MASTER OF ENGINEERING ( COMPUTER TECHNOLOGY & APPLICATIONS ) By ASHISH BHAWSAR College Roll No. 05/CTA/03 Delhi University Roll No. 3005 Under the guidance of Prof. Asok De Department Of Computer Engineering Delhi College Of Engineering, New Delhi-110042 (University of Delhi) July-2005 1 CERTIFICATE This is to certify that the dissertation entitled “MyFS: An Enhanced File System for MINIX” submitted by Ashish Bhawsar in the partial fulfillment of the requirement for the award of degree of Master of Engineering in Computer Technology and Application, Delhi College of Engineering is an account of his work carried out under my guidance and supervision. Professor D. Roy Choudhury Professor Asok De Head of Department Head of Department Department of Computer Engineering Department of Information Technology Delhi College of Engineering Delhi College of Engineering Delhi Delhi 2 ACKNOWLEDGEMENT It is a great pleasure to have the opportunity to extent my heartiest felt gratitude to everybody who helped me throughout the course of this project. I would like to express my heartiest felt regards to Dr. Asok De, Head of the Department, Department of Information Technology for the constant motivation and support during the duration of this project. It is my privilege and owner to have worked under the supervision. His invaluable guidance and helpful discussions in every stage of this thesis really helped me in materializing this project. It is indeed difficult to put his contribution in few words. I would also like to take this opportunity to present my most sincere regards to Dr.
    [Show full text]
  • Composing Abstractions Using the Null-Kernel
    Composing Abstractions using the null-Kernel James Litton Deepak Garg University of Maryland Max Planck Institute for Software Systems Max Planck Institute for Software Systems [email protected] [email protected] Peter Druschel Bobby Bhattacharjee Max Planck Institute for Software Systems University of Maryland [email protected] [email protected] CCS CONCEPTS hardware, such as GPUs, crypto/AI accelerators, smart NICs/- • Software and its engineering → Operating systems; storage devices, NVRAM etc., and to efficiently support new Layered systems; • Security and privacy → Access control. application requirements for functionality such as transac- tional memory, fast snapshots, fine-grained isolation, etc., KEYWORDS that demand new OS abstractions that can exploit existing hardware in novel and more efficient ways. Operating Systems, Capability Systems At its core, the null-Kernel derives its novelty from being ACM Reference Format: able to support and compose across components, called Ab- James Litton, Deepak Garg, Peter Druschel, and Bobby Bhattachar- stract Machines (AMs) that provide programming interfaces jee. 2019. Composing Abstractions using the null-Kernel. In Work- at different levels of abstraction. The null-Kernel uses an ex- shop on Hot Topics in Operating Systems (HotOS ’19), May 13–15, 2019, Bertinoro, Italy. ACM, New York, NY, USA, 6 pages. https: tensible capability mechanism to control resource allocation //doi.org/10.1145/3317550.3321450 and use at runtime. The ability of the null-Kernel to support interfaces at different levels of abstraction accrues several 1 INTRODUCTION benefits: New hardware can be rapidly deployed using rela- tively low-level interfaces; high-level interfaces can easily Abstractions imply choice, one that OS designers must con- be built using low-level ones; and applications can benefit front when designing a programming interface to expose.
    [Show full text]
  • Open Ongtang-Phd-Dissertation.Pdf
    The Pennsylvania State University The Graduate School SECURING MOBILE PHONES IN THE EVOLVING MOBILE ECOSYSTEM A Dissertation in Computer Science and Engineering by Machigar Ongtang © 2010 Machigar Ongtang Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy August 2010 The dissertation of Machigar Ongtang was reviewed and approved∗ by the following: Patrick D. McDaniel Associate Professor of Computer Science and Engineering Dissertation Advisor, Chair of Committee Thomas F. La Porta Distinguished Professor of Computer Science and Engineering Trent Jaeger Associate Professor of Computer Science and Engineering Ling Rothrock Associate Professor of Industrial and Manufacturing Engineering Raj Acharya Professor of Computer Science and Engineering Department Head ∗Signatures are on file in the Graduate School. Abstract The revolution of mobile phone industry has been altering our life and business practices over the past few decades. Driven by user demands and technological advancement, we now experience rich mobile phone applications and sophisticated cellular services ranging from mobile payment, stock trading, to social networking, vehicle tracking to in-car control. As more players joining the community, this mobile phone environment has transformed into a complex network of interacting companies, known as mobile ecosystem. Unfortunately, this opening and converging mobile ecosystem has brought in more opportunities for more attacks on mobile phones, a key element of the system. This dissertation aims to achieve mobile phone security. We reveal two main chal- lenges that we need to overcome, namely developing a clear definition of secure phones, and building security infrastructure that imposes such definition on the phones. We also identify three key elements that contribute to the fidelity of mobile phones, namely, mobile phone platforms, mobile phone applications, and mobile content.
    [Show full text]
  • The Flask Security Architecture: System Support for Diverse Security Policies
    The Flask Security Architecture: System Support for Diverse Security Policies Ray Spencer Secure Computing Corporation Stephen Smalley, Peter Loscocco National Security Agency Mike Hibler, David Andersen, Jay Lepreau University of Utah http://www.cs.utah.edu/flux/flask/ Abstract and even many types of policies [1, 43, 48]. To be gen­ erally acceptable, any computer security solution must Operating systems must be flexible in their support be flexible enough to support this wide range of security for security policies, providing sufficient mechanisms for policies. Even in the distributed environments of today, supporting the wide variety of real-world security poli­ this policy flexibility must be supported by the security cies. Such flexibility requires controlling the propaga­ mechanisms of the operating system [32]. tion of access rights, enforcing fine-grained access rights and supporting the revocation of previously granted ac­ Supporting policy flexibility in the operating system is cess rights. Previous systems are lacking in at least one a hard problem that goes beyond just supporting multi­ of these areas. In this paper we present an operating ple policies. The system must be capable of supporting system security architecture that solves these problems. fine-grained access controls on low-level objects used to Control over propagation is provided by ensuring that perform higher-level functions controlled by the secu­ the security policy is consulted for every security deci­ rity policy. Additionally, the system must ensure that sion. This control is achieved without significant perfor­ the propagation of access rights is in accordance with mance degradation through the use of a security decision the security policy.
    [Show full text]
  • Harvard Cs252r Fa'13
    Type Enforcement & Pluggable MAC Harvard CS252r Fa’13 Tuesday, October 22, 13 1 Practical Domain and Type Enforcement for UNIX • Badger, et al. 1995 • Trusted Information Systems Tuesday, October 22, 13 2 Domain and Type Enforcement • Every Subject is associated with a Domain • Every Object is associated with a Type Tuesday, October 22, 13 3 Boebart and Kain ’85 [7], page 23 introduces this a given user could have multiple subjects operating in diferent domains dynamically, it seems a subject and an object are associated with just one, statically: could be anything Domain and Type Enforcement • Domain Definition Table • Domain’s Access Rights to each Type • read, write, etc. • Domain Interaction Table • Domain’s Access Rights to other Domains • signal, create, destroy, etc. Tuesday, October 22, 13 4 Domain and Type Enforcement • Strict Superset of Lattice-Expressible Security Policies Tuesday, October 22, 13 5 Domain and Type Enforcement Manager budget designs Accountant Engineer salary Tuesday, October 22, 13 6 DTEL Domain and Type Enforcement Language • Encompasses Existing Security Policies • Hierarchical Types • Simple, Declarative Language Tuesday, October 22, 13 7 DTEL Operating System Entities File Hierarchy Process Hierarchy Figure 1: Mismatch Between Policy Concepts and System Structures trol configurations. A DTE specification includes ration: the type statement, the domain statement, the security attribute associations such as typelfile tnitial-domain statement, and the assign statement.’ associations as well as other access control in- The purpose of this section is not to fully document Tuesday,formation. October 22, 13 The language provides a high-level DTEL, but to demonstrate through a small example 8 view of information traditionally enurnerated in that a meaningful DTEL policy can be expressed com- type enforcement tables and includes facilities pletely in a form simple and concise enough to be ad- for superimposing security attribute bindings and ministered at reasonable cost.
    [Show full text]