Towards Access Control for Isolated Applications

Slides:



Advertisements
Similar presentations
PlanetLab Operating System support* *a work in progress.
Advertisements

The Multikernel: A new OS architecture for scalable multicore systems Andrew Baumann et al CS530 Graduate Operating System Presented by.
Introduction to Operating Systems CS-2301 B-term Introduction to Operating Systems CS-2301, System Programming for Non-majors (Slides include materials.
Slide 3-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 3 Operating System Organization.
Secure Operating System Architectures Patterns
Microkernels, virtualization, exokernels Tutorial 1 – CSC469.
UNIX System Administration OS Kernal Copyright 2002, Dr. Ken Hoganson All rights reserved. OS Kernel Concept Kernel or MicroKernel Concept: An OS architecture-design.
Chapter 6 Operating System Support. This chapter describes how middleware is supported by the operating system facilities at the nodes of a distributed.
Operating System Support for Virtual Machines Samuel T. King, George W. Dunlap,Peter M.Chen Presented By, Rajesh 1 References [1] Virtual Machines: Supporting.
Three fundamental concepts in computer security: Reference Monitors: An access control concept that refers to an abstract machine that mediates all accesses.
CSE 451: Operating Systems Section 10 Project 3 wrap-up, final exam review.
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg This material is made available for private study and for direct.
Slide 3-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 3.
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
G53SEC 1 Reference Monitors Enforcement of Access Control.
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking.
Operating System Organization Chapter 3 Michelle Grieco.
Intel Research & Development ETA: Experience with an IA processor as a Packet Processing Engine HP Labs Computer Systems Colloquium August 2003 Greg Regnier.
 Copyright 2005 Digital Enterprise Research Institute. All rights reserved. Enabling Components Management and Dynamic Execution Semantic.
UNIX Unit 1- Architecture of Unix - By Pratima.
A. Frank - P. Weisberg Operating Systems Structure of Operating Systems.
Full and Para Virtualization
1 Isolating Web Programs in Modern Browser Architectures CS6204: Cloud Environment Spring 2011.
Cloud Computing – UNIT - II. VIRTUALIZATION Virtualization Hiding the reality The mantra of smart computing is to intelligently hide the reality Binary->
IT 5433 LM1. Learning Objectives Understand key terms in database Explain file processing systems List parts of a database environment Explain types of.
1 Chapter 2: Operating-System Structures Services Interface provided to users & programmers –System calls (programmer access) –User level access to system.
Cofax Scalability Document Version Scaling Cofax in General The scalability of Cofax is directly related to the system software, hardware and network.
Towards a High Performance Extensible Grid Architecture Klaus Krauter Muthucumaru Maheswaran {krauter,
Chapter 2 Operating System Overview Dave Bremer Otago Polytechnic, N.Z. ©2008, Prentice Hall Operating Systems: Internals and Design Principles, 6/E William.
Distributed Systems Architectures Chapter 12. Objectives  To explain the advantages and disadvantages of different distributed systems architectures.
70-290: MCSE Guide to Managing a Microsoft Windows Server 2003 Environment, Enhanced Chapter 7: Advanced File System Management.
Introduction to Operating Systems Concepts
Computer System Structures
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Processes and threads.
CIIT-Human Computer Interaction-CSC456-Fall-2015-Mr
OpenMosix, Open SSI, and LinuxPMI
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Distribution and components
Operating System Structure
The Client/Server Database Environment
Introduction to Operating System (OS)
FICEER 2017 Docker as a Solution for Data Confidentiality Issues in Learning Management System.
University of Technology
Chapter 3: Windows7 Part 4.
Operating Systems and Systems Programming
Replication Middleware for Cloud Based Storage Service
Advanced Operating Systems
Chapter 2: System Structures
Operating Systems Bina Ramamurthy CSE421 11/27/2018 B.Ramamurthy.
Chapter 3: Operating-System Structures
Introduction to Databases Transparencies
Operating Systems : Overview
Outline Announcements Lab2 Distributed File Systems 1/17/2019 COP5611.
Multithreaded Programming
Chapter 2: Operating-System Structures
Chapter 2: The Linux System Part 5
Introduction to Operating Systems
Prof. Leonardo Mostarda University of Camerino
Operating Systems : Overview
Operating Systems : Overview
Operating Systems: A Modern Perspective, Chapter 3
SCONE: Secure Linux Containers Environments with Intel SGX
Operating Systems : Overview
Operating Systems : Overview
Outline Review of Quiz #1 Distributed File Systems 4/20/2019 COP5611.
Outline Operating System Organization Operating System Examples
File System Management
Chapter 2: Operating-System Structures
In Today’s Class.. General Kernel Responsibilities Kernel Organization
Presentation transcript:

Towards Access Control for Isolated Applications SECRYPT 2016, Lisbon, Portugal Kirill Belyaev and Indrakshi Ray Computer Science Department Colorado State University Fort Collins, CO, USA

Introduction Growing trends Modern single machine instance can deploy large number of application and data services UNIX based OS is a good candidate Services can be deployed within Isolated Runtime Environments (IRE) IRE can have all the necessary libraries for service deployment

Introduction Sample deployment (1) Single data service can be partitioned into several components

Introduction Sample deployment (2) Single OS node can host multiple multi-component data services

Problem Limitations of OS Access Control Linux OS has no concept of application-level Access Control

Problem Privilege escalation Applications deployed with super-user privileges make them not bound to normal Access Control rules

Problem Limitations of UNIX IPC UNIX System V Inter-Process Communication (IPC) does not offer regulated way of inter-application interaction

Motivation How to provide Access Control (AC) at the granularity of individual applications? How to confine applications with minimum privileges without running them with super user privileges? How to enable controlled application interaction across isolated runtime environments (IREs) without reliance on conventional UNIX IPC mechanisms? How to provide manageable user-space AC interface for a large number of data services?

Proposed Contributions Develop a novel object-oriented framework for application- level AC in Linux: Capabilities Policy Class Model – enables management and enforcement of application-level resource control Communication Policy Class Model – enables management and enforcement of controlled inter-application interaction across isolated runtime environments Unified framework – combines both models in a unified abstraction

Proposed Contributions Unified Framework 2 types of policy classes to provide application-level Access Control

Outline Capabilities Policy Class Model Communication Policy Class Model Architecture Proposed Evaluation

Capabilities Policy Class Model

Capabilities Policy Class Model What we have Access to OS/hardware resources is managed through kernel-space Linux (POSIX) capabilities Capabilities split up super user privileges into independent fragments Capabilities can manage resource control on the principle of least privilege No user-friendly management layer to manage capabilities

Capabilities Policy Class Model Sample capabilities Linux capabilities for instance include: CAP_AUDIT_CONTROL - Enable and disable kernel auditing; change auditing filter rules; retrieve auditing status and filtering rules CAP_DAC_OVERRIDE - Bypass file read, write, and execute permission checks CAP_IPC_LOCK - Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2)) CAP_NET_ADMIN - Perform various network-related operations such as: interface configuration; administration of IP firewall, masquerading, and accounting; modify routing tables; bind to any address for transparent proxying; set type-of-service (TOS); clear driver statistics; set promiscuous mode; enabling multicasting; use setsockopt(2) to set the advanced socket options CAP_SYS_BOOT - Use reboot(2) and kexec_load(2) system calls

Capabilities Policy Class Model What we need Capabilities could be grouped into various policy classes

Capabilities Policy Class Model Operations The following high-level operations are proposed: create a capabilities policy class add/remove capabilities to/from a policy class show capabilities in a policy class add/remove applications to/from a policy class show/count apps in a policy class

Capabilities Policy Class Model Sample usage Here is how the model is used in practice: SHOW_CAPABILITIES; SHOW_POLICY_CLASSES; CREATE_POLICY_CLASS 1 general_applications_policy_class; ADD_POLICY_CLASS_POLICY 1 CAP_KILL; ADD_POLICY_CLASS_POLICY 1 CAP_CHOWN; MOVE_APP_TO_POLICY_CLASS /containers/A/apps/app-A 1; REMOVE_POLICY_CLASS_POLICY 1 CAP_CHOWN; SHOW_POLICY_CLASS_POLICIES 1; SHOW_POLICY_CLASS_APPS 1;

Communication Policy Class Model

Communication Policy Class Model What we have A group of applications (service components) may provide a single data service A single application can be partitioned into a set of compartments Applications in separate isolated runtime environments (IREs) need to communicate Communication often involves: sharing data objects Exchanging control objects

Communication Policy Class Model What we need Provide bidirectional replication of data objects Provide only unidirectional replication of data objects

Communication Policy Class Model Types of Communication Group of applications (service components) may: Coordinate - exchange of coordination messages Collaborate - share mutual data objects via replication

Communication Policy Class Model Properties Group of applications can communicate only within the same class

Communication Policy Class Model Operations The following high-level operations are proposed: create a communication policy class add/remove applications to/from a policy class show/count apps in a policy class add/remove associations of an app to request a replica of a data object(s) to/from a policy class enable/disable application coordination with other application(s) in a policy class

Architecture

Architecture System design (1) Unified framework proposed in the form of Linux Policy Machine

Architecture System design (2) Unified framework stored in the embedded Sqlite database

Architecture Communication design (1) Adapt indirect communication paradigm - tuple space to enforce decoupled content-based inter-application interaction

Architecture Communication design (2) - Limitations The basic model relies on a global shared RAM tuple space Has number of issues: Tuple collisions could happen Wide array of possible security attacks Overheads of memory utilization Could be inaccessible due to access control policies Suitable mainly for a single application with multiple threads

Architecture Communication design (3) - Adaptation Personal tuple space per application Disk/flash based implementation

Architecture Communication design (4) - Operations Propose a set of tentative operations - tuple space calculus: create tuple space delete tuple space read operation - returns the value of individual tuple without affecting the contents of a tuple space append operation - adds a tuple without affecting existing tuples in a tuple space take operation - returns a tuple while removing it from a tuple space

Architecture Communication design (5) - Patterns Application allowed to perform all calculus operations Policy Machine restricted to read and append operations

Architecture Communication design (6) – Tuple Types Control tuples - provide the instructions about coordination or sharing Content tuples - mechanism by which data gets shared across applications

Architecture Communication design (7) – Collaborative Transaction Policy machine periodically checks for the presence of control tuples

Architecture Communication design (8) – Coordinative Transaction Policy machine periodically checks for the presence of control tuples

Proposed Evaluation Capabilities policy classes do not incur performance overhead no extra disk I/O aside from the I/O load of the base system no additional memory utilization Communication policy classes are resource intensive Evaluate performance with integrated tuple space controller: Sizes of mediated data objects Number of communicating applications Disk I/O utilization CPU utilization RAM utilization

Summary Unified Framework consists of: model of Capabilities Policy Classes – regulates Linux capabilities on a per-application granularity model of Communication Policy Classes - regulates inter- application interaction Enforcement of the framework is done via: Capabilities model – Linux LibCap library Communication model – Tuple Space Library/Controller (to be developed) Targets deployment of decoupled multi-component data services on multi-core server instance

Future Work Address the distributed deployment of unified framework Address the problems of policy representation and validation Investigate additional security for tuple spaces on fast persistent storage Investigate scalability issues Investigate the applicability for Dockers Secure memory-resident tuple spaces might not be necessary – rather the continuation of usage of fast persistent storage (SSD, flash memory) is more promising. Here security issues pertaining to file system operations might be investigated. Also some encryption strategies for hiding the actual contents of control/content tuples from possible observer could be investigated – dynamic key-less encryption. Scalability issues – related to how many concurrent tuple space transactions we can handle on a single server instance without performance degradation for deployed services

Sample Service Policy in XML <?xml version="1.0" encoding="UTF-8"?> <AutomationPolicy productID=“EEZALAdapter“ version="3.2.2" xmlns="http://www.ibm.com/TSA/Policy.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xsi:schemaLocation="http://www.ibm.com/TSA/Policy.xsd EEZALPolicy.xsd "> <PolicyInformation> <PolicyName>Agentless adapter sample policy</PolicyName> <AutomationDomainName>AgentlessDomain</Automation DomainName> <PolicyToken>1.0.5</PolicyToken> <PolicyAuthor>LPM</PolicyAuthor> <PolicyDescription> Agentless adapter sample policy. --------------------------------------- --------------- </PolicyDescription> </PolicyInformation> ... </AutomationPolicy>

Policy orchestration mechanisms

Policy validation with XML content filtering engine

Thank you for your attention! Questions?