DOCSLIB.ORG

Robust Composition: Towards a Unified Approach To

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Robust Composition: Towards a Unified Approach To Robust Composition: Towards a Uni¯ed Approach to Access Control and Concurrency Control by Mark Samuel Miller A dissertation submitted to Johns Hopkins University in conformity with the requirements for the degree of Doctor of Philosophy. Baltimore, Maryland May, 2006 Copyright °c 2006, Mark Samuel Miller. All rights reserved. Permission is hereby granted to make and distribute verbatim copies of this document without royalty or fee. Permission is granted to quote excerpts from this documented provided the original source is properly cited. ii Abstract When separately written programs are composed so that they may cooperate, they may instead destructively interfere in unanticipated ways. These hazards limit the scale and functionality of the software systems we can successfully compose. This dissertation presents a framework for enabling those interactions between components needed for the cooperation we intend, while minimizing the hazards of destructive interference. Great progress on the composition problem has been made within the object paradigm, chiefly in the context of sequential, single-machine programming among benign components. We show how to extend this success to support robust composi- tion of concurrent and potentially malicious components distributed over potentially malicious machines. We present E, a distributed, persistent, secure programming language, and CapDesk, a virus-safe desktop built in E, as embodiments of the tech- niques we explain. Advisor: Jonathan S. Shapiro, Ph.D. Readers: Scott Smith, Ph.D., Yair Amir, Ph.D. iii iv This dissertation is dedicated to the number \3469" and the letter \E". v vi Acknowledgements Jonathan Shapiro, my advisor, for encouraging me to continue this work in an aca- demic setting, and for providing insight, encouragement, and support way beyond the call of any duty. Terry Stanley, for her patient support, encouragement, and enthusiam for this project. My parents, Ann and Bernard Miller. Knowing the naches they would feel, helped motivate me to complete this dissertation (\Naches" is approximately \re- flected pride"). Hewlett-Packard Laboratories for supporting portions of this research, and Alan Karp for helping to arrange this. Combex and Henry Boreen for investing in these ideas. I still hope to see this investment pay o®. The Defense Advanced Research Projects Agency for sponsoring the security re- view of E, CapDesk, and the DarpaBrowser [WT02]. Lauren Williams for rescue from crisis. I don't know what would have happened without your help. The software systems explained in this dissertation are the results of collaborative e®orts starting at Electric Communities, Inc. and continuing with the e-lang online community. Since the contributors are many and changing, they are accurately docu- mented only by navigation from erights.org. Here, I'd like to single out and express my gratitude speci¯cally to E's most creative and proli¯c user, Marc Stiegler. He is the creator and primary developer of the systems documented in Part IV: CapDesk, Polaris, and the DarpaBrowser. Without his contributions, the value of E would have remained inaccessibly abstract. This dissertation borrows liberally from several of my previous papers [MMF00, MYS03, MS03, MTS04, MTS05]. Without further attribution, I'd like to especially thank my co-authors on these papers: Bill Frantz, Chip Morningstar, Jonathan Shapiro, E. Dean Tribble, Bill Tulloh, and Ka-Ping Yee. I cannot hope to enumerate all their contributions to the ideas presented here. I'd also like to thank again all those who contributed to these prior papers: Yair Amir, Paul Baclace, Darius Bacon, Howie Baetjer, Hans Boehm, Dan Bornstein, Per Brand, Marc \Lucky Green" Briceno, Michael Butler, Tyler Close, John Corbett, M. Scott Doerrie, Jed Donnelley, K. Eric Drexler, Ian Grigg, Norm Hardy, Chris Hibbert, Jack High, Tad Hogg, David Hopwood, Jim Hopwood, Ted Kaehler, Ken Kahn, Piotr vii Kaminski, Alan Karp, Terence Kelly, Lorens Kockum, Matej Kosik, Kevin Lacobie, Charles Landau, Jon Leonard, Mark Lillibridge, Brian Marick, Patrick McGeer, Eric Messick, Greg Nelson, Eric Northup, Constantine Plotnikov, Jonathan Rees, Kevin Reid, Matthew Roller, Vijay Saraswat, Christian Scheideler, Scott Smith, Michael Sperber, Fred Spiessens, Swaroop Sridhar, Terry Stanley, Marc Stiegler, Nick Szabo, Kazunori Ueda, David Wagner, Bryce \Zooko" Wilcox-O'Hearn, Steve Witham, and the e-lang and cap-talk communities. Thanks to Ka-Ping Yee and David Hopwood for a wide variety of assistance. They reviewed numerous drafts, contributed extensive and deep technical feedback, clar- ifying rephrasings, crisp illustrations, and moral support. Ka-Ping Yee contributed Figures 14.2 (p. 107), 14.3 (p. 108), 16.1 (p. 118), and 17.1 (p. 124) with input from the e-lang community. Thanks to Terry Stanley for suggesting the listener pattern and purchase-order examples. Thanks to Marc Stiegler for the membrane example shown in Figure 9.3 (p. 71). Thanks to Darius Bacon for the promise pipelining ex- ample shown in Figure 16.1 (p. 118). Thanks to Mark Seaborn for suggesting that the when-catch expression evaluate to a promise for its handler's result, as explained in Section 18.1. Thanks to the Internet Assigned Numbers Authority, for choosing the perfect port number for Pluribus on their own. Thanks to Norm Hardy for bringing to my attention the relationship between knowledge and authority in computational systems. For helpful suggestions regarding the dissertation itself, I thank Yair Amir, Tyler Close, M. Scott Doerrie, K. Eric Drexler, Bill Frantz, Norm Hardy, Chris Hibbert, Ken Kahn, Alan Karp, Patrick McGeer, Chip Morningstar, Eric Northup, Jonathan Shapiro, Matthew Roller, Scott Smith, Mark Smotherman, Swaroop Sridhar, Terry Stanley, Marc Stiegler, E. Dean Tribble, Bill Tulloh, and Lauren Williams. I am eternally grateful to the board of Electric Communities for open sourcing E when their business plans changed. Thanks to Kevin Reid and E. Dean Tribble for keeping the E development process alive and well while I spent time on this dissertation. viii Contents Abstract iii Acknowledgements vii List of Tables xv List of Figures xvii 1 Introduction 1 1.1 Organization of this Dissertation ........................ 2 2 Approach and Contributions 5 2.1 Unattenuated Composition ........................... 5 2.2 Attenuating Authority .............................. 6 2.3 Distributed Access Control ........................... 6 2.4 Distributed Concurrency Control ........................ 7 2.5 Promise Pipelining ................................ 9 2.6 Delivering Messages in E-ORDER ....................... 9 2.7 Emergent Robustness .............................. 10 I The Software Composition Problem 13 3 Fragile Composition 15 3.1 Excess Authority: The Gateway to Abuse ................... 16 3.2 How Much Authority is Adequate? ....................... 17 3.3 Shared-State Concurrency is Di±cult ...................... 18 3.4 Why a Uni¯ed Approach? ............................ 19 3.5 Notes on Related Work on Designation ..................... 20 4 Programs as Plans 23 4.1 Using Objects to Organize Assumptions .................... 23 4.1.1 Decomposition .............................. 23 4.1.2 Encapsulation ............................... 24 4.1.3 Abstraction ................................ 24 4.1.4 Composition ............................... 25 4.2 Notes on Related Work ............................. 26 ix 5 Forms of Robustness 29 5.1 Vulnerability Relationships ........................... 29 5.2 Platform Risk ................................... 30 5.3 Conventional Correctness ............................ 30 5.4 Cooperative Correctness ............................. 31 5.5 Defensive Correctness .............................. 32 5.6 Defensive Consistency .............................. 32 5.7 A Practical Standard for Defensive Programming . 33 5.8 Notes on Related Work ............................. 35 6 A Taste of E 39 6.1 From Functions to Objects ........................... 39 6.1.1 Lambda Abstraction ........................... 39 6.1.2 Adding Message Dispatch ........................ 40 6.1.3 Adding Side E®ects ........................... 42 6.2 Composites and Facets .............................. 42 6.3 Soft Type Checking ............................... 44 6.4 Notes on Related Work ............................. 46 7 A Taste of Pluribus 49 7.1 Pointer Safety ................................... 49 7.2 Distributed Objects ............................... 50 7.3 Distributed Pointer Safety ............................ 51 7.4 Bootstrapping Initial Connectivity ....................... 52 7.5 No Central Points of Failure ........................... 52 7.6 Notes on Related Work ............................. 53 II Access Control 55 8 Bounding Access Rights 57 8.1 Permission and Authority ............................ 58 8.2 Notes on Related Work ............................. 61 9 The Object-Capability Paradigm 63 9.1 The Object-Capability Model .......................... 64 9.2 Reference Graph Dynamics ........................... 66 9.2.1 Connectivity by Initial Conditions ................... 66 9.2.2 Connectivity by Parenthood ....................... 66 9.2.3 Connectivity by Endowment ...................... 66 9.2.4 Connectivity by Introduction ...................... 67 9.2.5 Only Connectivity Begets Connectivity . 68 9.3 Selective Revocation: Redell's Caretaker Pattern . 68 9.4 Analysis and Blind Spots ............................ 70 9.5 Access Abstraction ...............................
Load more

Recommended publications
  • Guidelines and Strategies for Secure Interaction Design
    ,ch13.10831 Page 253 Friday, August 5, 2005 10:12 PM Chapter 13 CHAPTER THIRTEEN Guidelines and Strategies for Secure Interaction Design KA-PING YEE ALTHOUGH A RELIABLE, USABLE AUTHENTICATION METHOD IS ESSENTIAL, it is far from the only human interface concern. After a user signs in to a system, the system has to carry out the user’s wishes correctly in order to be considered secure. The question of secure inter- action design, addressed in this and the other chapters in this part of the book, is: How can we design a computer system to protect the interests of its legitimate user? To give you a sense of how important it is to look beyond authentication, consider some of today’s most serious security problems. Viruses are a leading contender, with email viruses making up a large part. Spyware is growing into a nightmare for home users and IT staff. Identity theft is becoming widespread, perpetrated in part through “phishing” scams in which forged email messages entice people to give away private information. None of these problems is caused by defeating a login mechanism. They would be better described as failures of computers to behave as their users expect. This chapter suggests some guidelines for designing and evaluating usable secure software and proposes two strategies for getting security and usability to work in harmony: security by designation and user-assigned identifiers. I’ll begin by providing a little background for our discussion, then present the guidelines and strategies, and finally look at real design problems to show how these strategies can be applied in practice.
    [Show full text]
  • Human Factors and Usability Issues Have Traditionally Played a Limited Role in Security Research and Secure Systems Development
    Security and Usability By Lorrie Faith Cranor, Simson Garfinkel ............................................... Publisher: O'Reilly Pub Date: August 2005 ISBN: 0-596-00827-9 Pages: 738 Table of Contents | Index Human factors and usability issues have traditionally played a limited role in security research and secure systems development. Security experts have largely ignored usability issues--both because they often failed to recognize the importance of human factors and because they lacked the expertise to address them. But there is a growing recognition that today's security problems can be solved only by addressing issues of usability and human factors. Increasingly, well-publicized security breaches are attributed to human errors that might have been prevented through more usable software. Indeed, the world's future cyber-security depends upon the deployment of security technology that can be broadly used by untrained computer users. Still, many people believe there is an inherent tradeoff between computer security and usability. It's true that a computer without passwords is usable, but not very secure. A computer that makes you authenticate every five minutes with a password and a fresh drop of blood might be very secure, but nobody would use it. Clearly, people need computers, and if they can't use one that's secure, they'll use one that isn't. Unfortunately, unsecured systems aren't usable for long, either. They get hacked, compromised, and otherwise rendered useless. There is increasing agreement that we need to design secure systems that people can actually use, but less agreement about how to reach this goal. Security & Usability is the first book-length work describing the current state of the art in this emerging field.
    [Show full text]
  • Tahoe-LAFS Documentation Release 1.X
    Tahoe-LAFS Documentation Release 1.x The Tahoe-LAFS Developers Sep 22, 2021 Contents 1 Welcome to Tahoe-LAFS! 3 1.1 What is Tahoe-LAFS?..........................................3 1.2 What is “provider-independent security”?................................3 1.3 Access Control..............................................4 1.4 Get Started................................................4 1.5 License..................................................5 2 Installing Tahoe-LAFS 7 2.1 Microsoft Windows...........................................7 2.2 Linux, BSD, or MacOS.........................................8 3 Building Tahoe-LAFS on Windows9 4 Building Tahoe-LAFS on Linux 11 4.1 Prerequisites............................................... 11 4.2 Install the Latest Tahoe-LAFS Release................................. 12 5 Building Tahoe-LAFS On A Desert Island 13 5.1 How This Works............................................. 14 6 How To Run Tahoe-LAFS 17 6.1 Introduction............................................... 17 6.2 Do Stuff With It............................................. 19 6.3 Socialize................................................. 20 6.4 Complain................................................. 20 7 Magic Wormhole Invites 21 7.1 Magic Wormhole............................................. 21 7.2 Invites and Joins............................................. 21 7.3 Tahoe-LAFS Secret Exchange...................................... 21 8 Configuring a Tahoe-LAFS node 23 8.1 Node Types...............................................
    [Show full text]
  • Mickaël Salaün Intégration De L'utilisateur Au Contrôle D'accès
    THÈSE DE DOCTORAT DE TÉLÉCOM SUDPARIS Spécialité Informatique École doctorale Informatique, Télécommunications et Électronique (Paris) Présentée par Mickaël Salaün Pour obtenir le grade de DOCTEUR de TÉLÉCOM SUDPARIS Sujet de la thèse : Intégration de l’utilisateur au contrôle d’accès : du processus cloisonné à l’interface homme-machine de confiance Soutenue le 2 mars 2018 devant le jury composé de : Président : Gaël Thomas Télécom SudParis Rapporteurs : Michaël Hauspie Université Lille 1, Sciences et Technologies Valérie Viet Triem Tong CentraleSupélec Examinateur : Roland Groz Grenoble INP, Ensimag Directeur de thèse : Hervé Debar Télécom SudParis Co-encadrante : Marion Daubignard ANSSI Invités : Mathieu Blanc CEA Benjamin Morin ANSSI NNT : 2018TELE0006 c 2018 Mickaël Salaün Ce document est placé sous la « Licence Ouverte » publiée par la mission Etalab. Mise à jour du 6 avril 2018 Résumé Cette thèse souhaite fournir des outils pour qu’un utilisateur puisse contribuer activement à la sécurité de son usage d’un système informatique. Les activités de sensibilités différentes d’un utilisateur nécessitent tout d’abord d’être cloisonnées dans des domaines dédiés, par un contrôle d’accès s’ajustant aux besoins de l’utilisateur. Afin de conserver ce cloisonnement, celui-ci doit être en mesure d’identifier de manière fiable les domaines avec lesquels il interagit, à partir de l’interface de sa machine. Dans une première partie, nous proposons un nouveau mécanisme de cloisonnement qui peut s’adapter de manière transparente aux changements d’activité de l’utilisateur, sans altérer le fonctionnement des contrôles d’accès existants, ni dégrader la sécurité du système. Nous en décrivons une première implémentation, nommée StemJail, basée sur les espaces de noms de Linux.
    [Show full text]
  • Tahoe-Lafs-1.13.0.Tar.Bz2 Collecting
    Tahoe-LAFS Documentation Release 1.x The Tahoe-LAFS Developers Mar 03, 2021 Contents 1 Welcome to Tahoe-LAFS! 3 1.1 What is Tahoe-LAFS?..........................................3 1.2 What is “provider-independent security”?................................3 1.3 Access Control..............................................4 1.4 Get Started................................................4 1.5 License..................................................5 2 Installing Tahoe-LAFS 7 2.1 First: In Case Of Trouble.........................................7 2.2 Pre-Packaged Versions..........................................7 2.3 Preliminaries...............................................7 2.4 Install the Latest Tahoe-LAFS Release.................................9 2.5 Running the tahoe executable..................................... 10 2.6 Running the Self-Tests.......................................... 10 2.7 Common Problems............................................ 11 2.8 Using Tahoe-LAFS............................................ 11 3 How To Run Tahoe-LAFS 13 3.1 Introduction............................................... 13 3.2 Do Stuff With It............................................. 15 3.3 Socialize................................................. 16 3.4 Complain................................................. 16 4 Magic Wormhole Invites 17 4.1 Magic Wormhole............................................. 17 4.2 Invites and Joins............................................. 17 4.3 Tahoe-LAFS Secret Exchange.....................................
    [Show full text]