DOCSLIB.ORG

Linux Security Module Framework

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Linux Security Module Framework Linux Security Module Framework Chris Wright and Crispin Cowan ∗ Stephen Smalley † WireX Communications, Inc. NAI Labs, Network Associates, Inc. [email protected], [email protected] [email protected] James Morris Greg Kroah-Hartman Intercode Pty Ltd IBM Linux Technology Center [email protected] [email protected] Abstract 1 Introduction Security is a chronic and growing problem: as more Computer security is a chronic and growing prob- systems (and more money) go on line, the motiva- lem, even for Linux, as evidenced by the seem- tion to attack rises. Linux is not immune to this ingly endless stream of software security vulnera- threat: the “many eyes make shallow bugs” argu- bilities. Security research has produced numerous ment [24] not withstanding, Linux systems do expe- access control mechanisms that help improve sys- rience a large number of software vulnerabilities. tem security; however, there is little concensus on the best solution. Many powerful security systems An important way to mitigate software vulnera- have been implemented as research prototypes or bilities is through effective use of access controls. highly specialized products, leaving systems opera- Discretionary access controls (root, user-IDs and tors with a difficult challenge: how to utilize these mode bits) are adequate for user management of advanced features, without having to throw away their own privacy, but are not sufficient to pro- their existing systems? tect systems from attack. Extensive research in non-discretionary access control models has been The Linux Security Modules (LSM) project ad- done for over thirty years [1, 25, 17, 9, 15, 4, 19] dresses this problem by providing the Linux kernel but there has been no real consensus on which with a general purpose framework for access control. is the one true access control model. Because of LSM enables loading enhanced security policies as this lack of consensus, there are many patches to kernel modules. By providing Linux with a stan- the Linux kernel that provide enhanced access con- dard API for policy enforcement modules, the LSM trols [6, 10, 11, 13, 16, 18, 23, 19, 31] but none of project hopes to enable widespread deployment of them are a standard part of the Linux kernel. security hardened systems. This paper presents the design and implementation of the LSM framework, The Linux Security Modules (LSM) [29, 26, 30] a discussion of performance and security impact on project seeks to solve this Tower of Babel quandry the kernel, and a brief overview of existing security by providing a general purpose framework for se- modules. curity policy modules. This allows many different access control models to be implemented as load- able kernel modules, enabling multiple threads of security policy engine development to proceed inde- pendently of the main Linux kernel. A number of existing enhanced access control implementations, including POSIX.1e capabilities [28], SELinux, Do- ∗ This work supported in part by DARPA Contract main and Type Enforcement (DTE) [13] and Linux N66001-00-C-8032 (Autonomix) †This work supported by NSA Contract MDA904-01-C- Intrusion Detection System (LIDS) [16] have al- 0926 (SELinux) ready been adapted to use the LSM framework. The remainder of this paper is organized as follows. calls as they enter the kernel) or device mediation Section 2 presents the LSM design and implemen- (mediating at access to physical devices).1 The rea- tation. Ssection 3 gives a detailed look at the LSM son is that information critical to sound security pol- interface. Section 4 describes the impact LSM has icy decisions is not available at those points. At the on permformance and security, including a look at system call interface, userspace data, such as a path some projects that have been ported to LSM so far. name, has yet to be translated to the kernel object Section 5 presents our conclusions. it represents, such as an inode. Thus, system call interpostion is both inefficient and prone to time-of- check-to-time-of-use (TOCTTOU) races [27, 5]. At the device interface, some other critical information 2 Design and Implementation (such as the path name of the file to be accessed) has been thrown away. In between is where the full context of an access request can be seen, and where At the 2001 Linux Kernel Summit, the NSA pre- a fully informed access control decision can be made. sented their work on Security-Enhanced Linux (SELinux) [18], an implementation of a flexible ac- A subtle implication of the LSM architecture is that cess control architecture in the Linux kernel. Li- access control decisions are restrictive2: the module nus Torvalds appeared to accept that a general can really only ever say “no” [30]. Functional errors access control framework for the Linux kernel is and classical security checks can result in an access needed. However, given the many Linux kernel se- request being denied before it is ever presented to curity projects, and Linus’ lack of expertise in so- the LSM module. This is the opposite of the way phisticated security policy, he preferred an approach mandatory access control systems are normally im- that allowed security models to be implemented as plemented. This design choice limits the flexibility loadable kernel modules. In fact, Linus’ response of the LSM framework, but substantially simplifies provided the seeds of the LSM design. The LSM the impact of the LSM on the Linux kernel. To do framework must be: otherwise would have required implementing many instances of the same hook throughout the kernel, to ensure that the module is consulted at every place • truly generic, where using a different security where a system call could “error out.” model is merely a matter of loading a different kernel module; Composition of LSM modules is another problem- • conceptually simple, minimally invasive, and atic issue. On the one hand, security policies do not efficient; and compose in the general case because some policies may explicitly conflict [12]. On the other hand, it • able to support the existing POSIX.1e capabil- is clearly desirable to compose some combinations ities logic as an optional security module. of security policies. Here, LSM effectively punts to the module writer: to be able to “stack” modules, To achieve these goals, while remaining agnostic the first module loaded must also export an LSM with respect to styles of access control mediation, interface to subsequent LSM modules to be loaded. LSM takes the approach of mediating access to the The first module is then responsible for composing kernel’s internal objects: tasks, inodes, open files, the access control decisions that it gets back from etc., as shown in Figure 1. User processes execute secondary modules. system calls, which first traverse the Linux kernel’s existing logic for finding and allocating resources, performing error checking, and passing the classi- cal Unix discretionary access controls. Just before the kernel would access the internal object, an LSM hook makes an out-call to the module posing the question “Is this access ok with you?” The mod- ule processes this policy question and returns either “yes” or “no.” 1The glib answer is the Linux kernel already provides those features and there would be nothing for us to do :-) 2Caveat: the capable() hook, which is needed to sup- One might ask why LSM chose this approach rather port POSIX.1e capabilities, can override DAC checks, see than system call interposition (mediating system Setion 3.7. User Level process User space open system call Kernel space Look up inode error checks LSM Module DAC checks Policy Engine "OK with you?" Examine context LSM hook Does request pass policy? Yes or No Grant or deny Complete request Access inode Figure 1: LSM Hook Architecture 3 LSM Interface policies to label a task with a policy specific security label. Having discussed the high-level design philosophies The LSM task hooks have full task life-cycle cov- of LSM in Section 2 we now turn to the implementa- erage. The create() task hook is called verifying tion of the LSM interface. At the core, the LSM in- that a task can spawn children. If this is successful, terface is a large table of functions, which by default a new task is created and the alloc security() are populated with calls that implement the tradi- task hook is used to manage the new task’s security tional superuser DAC policy. The module writer field. When a task exits, the kill() task hook is is then responsible for providing implementations consulted to verify that the task can signal its par- of the functions that they care about. This section ent. Similarly, the wait() task hook is called in the provides a detailed analysis of those functions.3 Sec- parent task context, verifying the parent task can tions 3.1 through 3.7 are organized by kernel object receive the child’s signal. And finally, the task’s se- and discuss the LSM interface available to mediate curity field is released by the free security() task access to each object. hook. During the life of a task it may attempt to change 3.1 Task Hooks some of its basic task information. For example a task may call setuid(2). This is, of course, man- aged by LSM with a corresponding setuid() task The task struct structure is the kernel object hook. If this is successful the kernel updates the representing kernel schedulable tasks. It contains task’s user identity and then notifies the policy mod- basic task information such as: user and group ule via the post setuid() task hook. The notifi- id, resource limits, and scheduling policies and cation allows the module to update state, and for priorites.
Load more

Recommended publications
  • Have You Driven an Selinux Lately? an Update on the Security Enhanced Linux Project
    Have You Driven an SELinux Lately? An Update on the Security Enhanced Linux Project James Morris Red Hat Asia Pacific Pte Ltd [email protected] Abstract All security-relevant accesses between subjects and ob- jects are controlled according to a dynamically loaded Security Enhanced Linux (SELinux) [18] has evolved mandatory security policy. Clean separation of mecha- rapidly over the last few years, with many enhancements nism and policy provides considerable flexibility in the made to both its core technology and higher-level tools. implementation of security goals for the system, while fine granularity of control ensures complete mediation. Following integration into several Linux distributions, SELinux has become the first widely used Mandatory An arbitrary number of different security models may be Access Control (MAC) scheme. It has helped Linux to composed (or “stacked”) by SELinux, with their com- receive the highest security certification likely possible bined effect being fully analyzable under a unified pol- for a mainstream off the shelf operating system. icy scheme. SELinux has also proven its worth for general purpose Currently, the default SELinux implementation com- use in mitigating several serious security flaws. poses the following security models: Type Enforcement (TE) [7], Role Based Access Control (RBAC) [12], While SELinux has a reputation for being difficult to Muilti-level Security (MLS) [29], and Identity Based use, recent developments have helped significantly in Access Control (IBAC). These complement the standard this area, and user adoption is advancing rapidly. Linux Discretionary Access Control (DAC) scheme. This paper provides an informal update on the project, With these models, SELinux provides comprehensive discussing key developments and challenges, with the mandatory enforcement of least privilege, confidential- aim of helping people to better understand current ity, and integrity.
    [Show full text]
  • Addressing Challenges in Automotive Connectivity: Mobile Devices, Technologies, and the Connected Car
    2015-01-0224 Published 04/14/2015 Copyright © 2015 SAE International doi:10.4271/2015-01-0224 saepcelec.saejournals.org Addressing Challenges in Automotive Connectivity: Mobile Devices, Technologies, and the Connected Car Patrick Shelly Mentor Graphics Corp. ABSTRACT With the dramatic mismatch between handheld consumer devices and automobiles, both in terms of product lifespan and the speed at which new features (or versions) are released, vehicle OEMs are faced with a perplexing dilemma. If the connected car is to succeed there has to be a secure and accessible method to update the software in a vehicle's infotainment system - as well as a real or perceived way to graft in new software content. The challenge has become even more evident as the industry transitions from simple analog audio systems which have traditionally served up broadcast content to a new world in which configurable and interactive Internet- based content rules the day. This paper explores the options available for updating and extending the software capability of a vehicle's infotainment system while addressing the lifecycle mismatch between automobiles and consumer mobile devices. Implications to the design and cost of factory installed equipment will be discussed, as will expectations around the appeal of these various strategies to specific target demographics. CITATION: Shelly, P., "Addressing Challenges in Automotive Connectivity: Mobile Devices, Technologies, and the Connected Car," SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 8(1):2015, doi:10.4271/2015-01-0224. INTRODUCTION be carefully taken into account. The use of app stores is expected to grow significantly in the coming years as automotive OEMs begin to Contemporary vehicle infotainment systems face an interesting explore apps not only on IVI systems, but on other components of the challenge.
    [Show full text]
  • (Un)Smashing the Stack
    Hello, Interwebs Hi, and thanks for reading this. As I mentioned a number of times during the talk this was one long, hard slog of a topic for me. My intent was not to duplicate existing research (Johnson and Silberman @ BHUS05, others), but to try to make this topic comprehensible for the typical security professional, who (GASP! SHOCK! HORROR!) may not necessarily grasp all the hairy internals of exploit development, but still is tasked with protecting systems. For the other 90% of us out there, our job is not to be leet, but rather not to get owned, something I hope to get a little bit better at every day. Since exploit mitigation is something that might bring us all a little bit closer to that, I wanted to explore the topic. Thanks much to BH for giving me the opportunity to do so, and to all of you for listening. Thanks also to all the amazing people working on these technologies, especially the PaX team and Hiroaki Etoh of IBM. -- shawn P.S. It’s actually Thompson that had the Phil Collins hair, not Ritchie. Sorry, Dennis. 28 75 6e 29 53 6d 61 73 68 69 6e 67 20 74 68 65 20 53 74 61 63 6b 0d 0a (un)Smashing the Stack 4f 76 65 72 66 6c 6f 77 73 2c 20 43 6f 75 6e 74 65 72 6d 65 61 73 75 72 65 73 20 61 6e 64 20 74 68 65 20 52 65 61 6c 20 57 6f 72 6c 64 Overflows, Countermeasures and the Real World Shawn Moyer :: Chief Researcher ---- SpearTip Technologies ---> blackhat [at] cipherpunx [dot] org Hey, who is this guy? ShawnM: InfoSec consultant, (quasi-) developer, husband, father, and raging paranoid with obsessive tendencies Chief Researcher at SpearTip Technologies Security Consultancy in Saint Louis, MO Forensics, Assessment, MSSP, network analysis Weddings, Funerals, Bar Mitzvahs I like unsolvable problems, so I’m mostly interested in defense.
    [Show full text]
  • Demystifying Internet of Things Security Successful Iot Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M
    Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security: Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Chandler, AZ, USA Chandler, AZ, USA Ned Smith David M. Wheeler Beaverton, OR, USA Gilbert, AZ, USA ISBN-13 (pbk): 978-1-4842-2895-1 ISBN-13 (electronic): 978-1-4842-2896-8 https://doi.org/10.1007/978-1-4842-2896-8 Copyright © 2020 by The Editor(s) (if applicable) and The Author(s) This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons license, unless indicated otherwise in a credit line to the material.
    [Show full text]
  • Debian \ Amber \ Arco-Debian \ Arc-Live \ Aslinux \ Beatrix
    Debian \ Amber \ Arco-Debian \ Arc-Live \ ASLinux \ BeatriX \ BlackRhino \ BlankON \ Bluewall \ BOSS \ Canaima \ Clonezilla Live \ Conducit \ Corel \ Xandros \ DeadCD \ Olive \ DeMuDi \ \ 64Studio (64 Studio) \ DoudouLinux \ DRBL \ Elive \ Epidemic \ Estrella Roja \ Euronode \ GALPon MiniNo \ Gibraltar \ GNUGuitarINUX \ gnuLiNex \ \ Lihuen \ grml \ Guadalinex \ Impi \ Inquisitor \ Linux Mint Debian \ LliureX \ K-DEMar \ kademar \ Knoppix \ \ B2D \ \ Bioknoppix \ \ Damn Small Linux \ \ \ Hikarunix \ \ \ DSL-N \ \ \ Damn Vulnerable Linux \ \ Danix \ \ Feather \ \ INSERT \ \ Joatha \ \ Kaella \ \ Kanotix \ \ \ Auditor Security Linux \ \ \ Backtrack \ \ \ Parsix \ \ Kurumin \ \ \ Dizinha \ \ \ \ NeoDizinha \ \ \ \ Patinho Faminto \ \ \ Kalango \ \ \ Poseidon \ \ MAX \ \ Medialinux \ \ Mediainlinux \ \ ArtistX \ \ Morphix \ \ \ Aquamorph \ \ \ Dreamlinux \ \ \ Hiwix \ \ \ Hiweed \ \ \ \ Deepin \ \ \ ZoneCD \ \ Musix \ \ ParallelKnoppix \ \ Quantian \ \ Shabdix \ \ Symphony OS \ \ Whoppix \ \ WHAX \ LEAF \ Libranet \ Librassoc \ Lindows \ Linspire \ \ Freespire \ Liquid Lemur \ Matriux \ MEPIS \ SimplyMEPIS \ \ antiX \ \ \ Swift \ Metamorphose \ miniwoody \ Bonzai \ MoLinux \ \ Tirwal \ NepaLinux \ Nova \ Omoikane (Arma) \ OpenMediaVault \ OS2005 \ Maemo \ Meego Harmattan \ PelicanHPC \ Progeny \ Progress \ Proxmox \ PureOS \ Red Ribbon \ Resulinux \ Rxart \ SalineOS \ Semplice \ sidux \ aptosid \ \ siduction \ Skolelinux \ Snowlinux \ srvRX live \ Storm \ Tails \ ThinClientOS \ Trisquel \ Tuquito \ Ubuntu \ \ A/V \ \ AV \ \ Airinux \ \ Arabian
    [Show full text]
  • A Framework for Prototyping and Testing Data-Only Rootkit Attacks
    1 A Framework for Prototyping and Testing Data-Only Rootkit Attacks Ryan Riley [email protected] Qatar University Doha, Qatar Version 1.0 This is a preprint of the paper accepted in Elsevier Computers & Security Abstract—Kernel rootkits—attacks which modify a running of 25 rootkit attacks to test with, but end up stating, “Of operating system kernel in order to hide an attacker’s presence— the 25 that we acquired, we were able to install 18 in our are significant threats. Recent advances in rootkit defense tech- virtual test infrastructure. The remainder either did not support nology will force rootkit threats to rely on only modifying kernel data structures without injecting and executing any new our test kernel version or would not install in a virtualized code; however these data-only kernel rootkit attacks are still environment.” In [2], the authors test with 16 Linux rootkits, both realistic and powerful. In this work we present DORF, a but only 12 of them overlap with [1]. In [3], the authors give framework for prototyping and testing data-only rootkit attacks. no results that involved testing with rootkit attacks. DORF is an object-oriented framework that allows researchers to As another example, in our own work involving kernel construct attacks that can be easily ported between various Linux distributions and versions. The current implementation of DORF rootkit defense [2], [4], [5], [6] we found ourselves locked in contains a group of existing and new data-only attacks, and the to an older version of Linux due to the rootkits we planned to portability of DORF is demonstrated by porting it to 6 different test with.
    [Show full text]
  • Linux Kernel Debugging and Security (Lfd440)
    Contact Us [email protected] HOME > COURSE CATALOG > LINUX FOUNDATION > SECURITY > LINUX KERNEL DEBUGGING AND SECURITY (LFD440) Linux Kernel Debugging and Security (LFD440) DURATION 4 Days COURSE LNX-LFD440 AVAILABLE FORMATS Classroom Training, Online Training Course Description Overview Learn the methods and internal infrastructure of the Linux kernel. This course focuses on the important tools used for debugging and monitoring the kernel, and how security features are implemented and controlled. Objectives This four day course includes extensive hands-on exercises and demonstrations designed to give you the necessary tools to develop and debug Linux kernel code. Students will walk away from this course with a solid understanding of Linux kernel. debugging techniques and tools. Audience 9/27/2021 1 of 11 1:47:42 PM This course is for experienced developers who need to understand the methods and internal infrastructure of the Linux kernel. Prerequisites To make the most of this course, you should: Be proficient in the C programming language; Be familiar with basic Linux (UNIX) utilities such as ls, grep and tar; Be comfortable using any of the available text editors (e.g. emacs, vi, etc.); Experience with any major Linux distribution is helpful but not strictly required; Have experience equivalent to having taken : Linux Kernel Internals and Development. Topics Introduction Objectives Who You Are The Linux Foundation Linux Foundation Training Certification Programs and Digital Badging Linux Distributions Platforms Preparing Your System
    [Show full text]
  • On the Quality of Exploit Code
    On the Quality of Exploit Code An Evaluation of Publicly Available Exploit Code, Hackers & Threats II, February 17, 2:00 PM, San Francisco, CA Ivan Arce, Core Security Technologies OUTLINE • Prologue: Context and definitions • Why exploit code? • Quality metrics • Examples • Epilogue: Future work PROLOGUE VULNERABILITIES & EXPLOITS Lets start by defining a common language • Vulnerability (noun) — “A flaw in a system that, if leveraged by an attacker, can potentially impact the security of said system” — Also: security bug, security flaw, security hole • Exploit (verb) — “To use or manipulate to one’s advantage” (Webster) — “A security hole or an instance of taking advantage of a security hole” EXPLOIT CODE Exploit code is not just “proof of concept” • Proof of Concept exploit - PoC (noun) — A software program or tool that exploits a vulnerability with the sole purpose of proving its existence. • Exploit Code (noun) — A software program or tool developed to exploit a vulnerability in order to accomplish a specific goal. — Possible goals: denial of service, arbitrary execution of code, etc An emerging role in the information security practice WHY TALK ABOUT EXPLOIT CODE? ANATOMY OF A REAL WORLD ATTACK The classic attack uses exploit code... ATTACKER Base Camp A target server is attacked and compromised The acquired server is used as vantage point to penetrate the corporate net Further attacks are performed as an internal user EXPLOIT CODE FUNCTIONALITY Exploit code becomes more sophisticated • Add a simple “listen shell” echo "ingreslock stream tcp nowait root /bin/sh sh -i" >>/tmp/bob ; /usr/sbin/inetd -s /tmp/bob &" • Add an account to the compromised system: echo "sys3:x:0:103::/:/bin/sh" >> /etc/passwd; echo "sys3:1WXmkX74Ws8fX/MFI3.j5HKahNqIQ0:12311:0:99999:7:::" >> /etc/shadow • Execute a “bind-shell” • Execute a “reverse shell” • Deploy and execute a multi-purpose agent Command shell, FTP, TFTP, IRC, “zombies”, snifers, rootkits..
    [Show full text]
  • Seth Arnold SARNOLD(7)
    SARNOLD(7) Seth Arnold SARNOLD(7) NAME Seth Arnold - sarnold(7) - +1-503-577-3453 - [email protected] SYNOPSIS I am versatile, able to quickly adapt to and excel in complex systems, especially those with subtle security and reliability problems. I enjoy talking with customers and users; my most recent supervisor noted I have a very good sense of the customer's voice. I support co-workers with enthusiasm, improving a team's productivity and morale. OPTIONS · 15 years experience developing software for Linux (Ubuntu, Debian, SuSE, Red Hat, Slackware, Caldera). · 6 years experience using OpenBSD, WinNT 4.0 / Win2K. · 4 years experience using NetWare 3.11, SCO 3.2.4.2, and SCO OpenServer 5.0. · Programming Languages: C, Ruby, Perl, Python, Java, Unix shell, SQL, HTML, LaTeX · Source code control systems: Git, Subversion, CVS, BitKeeper · Native English speaker; learning German I have expertise with Linux kernel internals, cryptography, security issues, software development and mainte- nance, and the TCP/IP family of protocols. I am familiar with the constraints and freedoms of open source licenses. I give confident, credible, and effective presentations about complex subjects. I participate in Free Software and Open Source communities. I have been part of the Open and Free Technology Community's NOC and a staff member on Freenode. HISTORY May 2005 { October 2007 Novell, Inc. / SuSE GmbH; Portland, OR, USA I joined the SuSE Labs research and development team when Novell acquired Immunix. My responsibilities at Novell / SuSE included: Software development Primary developer of AppArmor Mandatory Access Control policies for the SuSE Linux family of distribu- tions.
    [Show full text]
  • Trustworthy Whole-System Provenance for the Linux Kernel Adam Bates, Dave (Jing) Tian, and Kevin R.B
    Trustworthy Whole-System Provenance for the Linux Kernel Adam Bates, Dave (Jing) Tian, and Kevin R.B. Butler, University of Florida; Thomas Moyer, MIT Lincoln Laboratory https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/bates This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX Trustworthy Whole-System Provenance for the Linux Kernel Adam Bates, Dave (Jing) Tian, Thomas Moyer Kevin R.B. Butler University of Florida MIT Lincoln Laboratory {adammbates,daveti,butler}@ufl.edu [email protected] Abstract is presently of enormous interest in a variety of dis- In a provenance-aware system, mechanisms gather parate communities including scientific data processing, and report metadata that describes the history of each ob- databases, software development, and storage [43, 53]. ject being processed on the system, allowing users to un- Provenance has also been demonstrated to be of great derstand how data objects came to exist in their present value to security by identifying malicious activity in data state. However, while past work has demonstrated the centers [5, 27, 56, 65, 66], improving Mandatory Access usefulness of provenance, less attention has been given Control (MAC) labels [45, 46, 47], and assuring regula- to securing provenance-aware systems. Provenance it- tory compliance [3]. self is a ripe attack vector, and its authenticity and in- Unfortunately, most provenance collection mecha- tegrity must be guaranteed before it can be put to use.
    [Show full text]
  • IBM Research Report Docker and Container Security White Paper
    RC25625 (WAT1607-027) July 15, 2016 Computer Science IBM Research Report Docker and Container Security White Paper Salman Baset, Stefan Berger, James Bottomley, Canturk Isci, Nataraj Nagaratnam1, Dimitrios Pendarakis, J. R. Rao, Gosia Steinder, Jayashree Ramanatham1 IBM Research Division Thomas J. Watson Research Center P.O. Box 218 Yorktown Heights, NY 10598 USA 1IBM Cloud Research Division Almaden – Austin – Beijing – Brazil – Cambridge – Dublin – Haifa – India – Kenya – Melbourne – T.J. Watson – Tokyo – Zurich Docker and Container Security White Paper Contributors: Salman Baset, Stefan Berger, James Bottomley, Canturk Isci, Nataraj Nagaratnam, Dimitrios Pendarakis, JR Rao, Gosia Steinder, Jayashree Ramanatham Introduction This paper presents IBM's comprehensive point of view of security and privacy for Cloud Computing services based on container technologies, in particular Docker containers. The objective is to highlight benefits as well as security challenges for Docker containers, highlight ongoing efforts that address these challenges and to motivate additional work that the Docker community and IBM are undertaking to further strengthen the security of the Docker container ecosystem. Potential users of Docker container based cloud services can use this paper to evaluate the benefits and risks associated with deploying various workloads on Docker containers, understand the evolution of Docker containers and decide what additional security mechanisms and tools to employ to further reduce security risks. The paper starts with an overview of the applicable threat model and then compares the security properties of base technologies such as Linux containers, Docker, as well hypervisors, which are the basis of Infrastructure as a Service (IaaS) offerings. Next we describe some of the gaps in security for Docker containers and how IBM has helped and continues to help the community to address them.
    [Show full text]
  • A Tamper-Resistant Framework for Unambiguous Detection of Attacks in User Space Using Process Monitors
    A Tamper-Resistant Framework for Unambiguous Detection of Attacks in User Space Using Process Monitors Ramkumar Chinchani and Shambhu Upadhyaya Kevin Kwiat Dept. of Computer Science and Engineering Air Force Research Laboratory University at Buffalo, SUNY 525 Brooks Road Amherst, NY 14260 Rome, NY 13441 Email: rc27, shambhu ¡ @cse.buffalo.edu Email: [email protected] Abstract with large projects [14], [9], [12], [11] suggest this. Maintaining high availability of these services is criti- Replication and redundancy techniques rely on the as- cal for the smooth functioning of any organization relying sumption that a majority of components are always safe and on those resources. These services can fail due to software voting is used to resolve any ambiguities. This assumption faults or attacks by intruders. Occurrence of faults can result may be unreasonable in the context of attacks and intru- in the unpredictable failure of the system. Intrusions are of- sions. An intruder could compromise any number of the ten likened to faults and successful attacks, like faults, leave available copies of a service resulting in a false sense of the system in an inconsistent or unusable state. security. The kernel based approaches have proven to be Fault detection and tolerance techniques have goals such quite effective but they cause performance impacts if any as dependability, reliability, availability, safety and per- code changes are in the critical path. In this paper, we pro- formability which are similar to the goals of intrusion pre- vide an alternate user space mechanism consisting of pro- vention and detection, and other security measures. How- cess monitors by which such user space daemons can be ever, the correspondence is not always one to one.
    [Show full text]