Towards Access Control for Isolated Applications

Kirill Belyaev and Indrakshi Ray Computer Science Department, Colorado State University, Fort Collins, U.S.A

Keywords: Access Control, Service and Systems Design, Inter-application Communication.

Abstract: With the advancements in contemporary multi-core CPU architectures, it is now possible for a (OS), such as Linux, to a large number of concurrent application services on a single server instance. Individual application components of such services may run in different isolated runtime environ- ments, such as chrooted jails or application containers, and may need access to system resources and the ability to collaborate and coordinate with each other in a regulated and secure manner. We propose an access control framework for policy formulation, management, and enforcement that allows access to OS resources and also permits controlled collaboration and coordination for service components running in disjoint containerized environments under a single Linux OS server instance. The framework consists of two models and the policy formulation is based on the concept of policy classes for ease of administration and enforcement. The policy classes are managed and enforced through a Linux Policy Machine (LPM) that acts as the centralized reference monitor and provides a uniform interface for accessing system resources and requesting application data and control objects. We present the details of our framework and also discuss the preliminary implementation to demonstrate the feasibility of our approach.

1 INTRODUCTION plications for controlling access to OS resources, for regulating the access requests to the application data The advancements in contemporary multi-core CPU and control objects used for inter-application commu- architectures have greatly improved the ability of nication between service components. modern server operating systems (OS) such as Linux For instance, consider a real-world service deploy- to deploy a large number of concurrent application ment scenario taken from the actual telecom service services on a single server instance. The emergence of provider (n–Logic Ltd., 2016). A Linux server has application containers (Docker Developers, 2016), in- three applications, namely, Squid Web Cache Server, troduction of support for kernel namespaces (Manual, Squid Log Analyzer, and HTTP Web Server, deployed 2016) allows a set of loosely coupled service compo- in three separate isolated environments (chrooted jail nents to be executed in isolation from each other and directories), each under a distinct unprivileged user also from the main operating system. This enables ap- identifier (UID). Combined all three applications rep- plication service providers to lower their total cost of resent individual components of a single service – ownership by deploying large numbers of application ISP web caching that caches HTTP traffic of services on a single server instance and possibly min- a large customer base to minimize the utilization of imize horizontal scaling of applications across multi- ISP’s Internet backbone. Squid Web Cache Server ple nodes. component needs access to I/O re- In conventional or Linux OS, applications sources and some advanced networking capabilities can be deployed in isolated (containerized) environ- of the Linux kernel in order to operate. However, we ments, such as chrooted jails. Such isolated envi- cannot allow this component to run under a super-user ronments limit the access of the applications beyond to obtain unrestricted root privileges. Allowing root some designated directory tree and have the potential access to an application opens possibilities for system to offer enhanced security and performance. How- security breaches and can even compromise the entire ever, no mechanism is provided for controlled com- OS. munication and sharing of data objects between iso- A new mechanism of access control needs to be lated applications across such environments. A new enforced for such a component to run under unpriv- type of access control is needed for such isolated ap- ileged UID but still be able to access necessary OS

171

Belyaev, K. and Ray, I. Towards Access Control for Isolated Applications. DOI: 10.5220/0005970001710182 In Proceedings of the 13th International Joint Conference on e-Business and Telecommunications (ICETE 2016) - Volume 4: SECRYPT, pages 171-182 ISBN: 978-989-758-196-0 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

SECRYPT 2016 - International Conference on Security and Cryptography

resources. Squid Web Cache Server component gen- and also provide rules such that only applications be- erates daily operational cache logs in its respective longing to the same communicative policy class can runtime environment. Squid Log Analyzer component communicate using this approach. The communica- needs to perform data analytics on those operational tion between applications is mediated through a com- log files on a daily basis. It then creates analytical ponent of the LPM which is allowed limited access to results in the form of HTML files that need to be ac- an application’s tuple space. Consider, for example, a cessible by the HTTP Web Server component to be described web caching data service that is partitioned available through the web browser for administrative into three components, each in a separate chrooted jail personnel. In such a case, there is a need to access for security purposes. Our LPM allows a regulated and share data objects across the applications in dis- way of coordinating and collaborating among com- joint containerized environments. Note that, there are ponents using tuple spaces. Note that, such coordina- no shared data objects by which such communication tion and collaboration will be allowed even if each of can take place. Usual Inter- Communication the components executes under different system UIDs (IPC) primitives such as message queues, memory- and even group identifier (GID). mapped files and may cause unautho- Our uniform framework provides a coherent busi- rized access or illegal information flow. In fact, IPC ness logic interface available to administrative per- could be disabled to minimize such security breaches. sonnel to manage access control for an application Moreover, legacy byte-level constructs, such as IPC, both at the level of OS resources and at the level of often do not fit under the development framework of inter-application interaction. Such a centralized LPM modern applications that operate at the granularity of construct that is resident in user-space acts as a refer- higher-level message objects. In such enterprise en- ence monitor for a set of administered data services vironments, a novel paradigm is needed for efficient deployed on a single Linux server instance. We in- and secure communication among isolated processes. corporate the access control modelling and decision Such coordination and sharing of data must take place control in user-space with robust and expressive per- in a controlled manner. Here again, an access control sistence layer. This allows high interoperability and mechanism is needed that will allow this to happen. usage of the framework on any general-purpose Linux We introduce a new framework referred to as OS without a requirement for custom kernel patching Linux Policy Machine (and shorten it to just LPM (Krohn et al., 2007). in the rest of the paper) to address the identified The rest of the paper is organized as follows. challenges. Our LPM allows the management and Section 2 gives a detailed overview of the model to enforcement of access to OS resources for individ- manage capabilities using policy classes abstraction. ual applications and it also allows regulated inter- Section 3 describes the proposed model for inter- application communication. application communication across isolated environ- ments. Section 4 describes the design of the inter- We propose the notion of capabilities policy application communication architecture. Section 5 classes, each of which is associated with a set of ca- demonstrates the feasibility of our approach by de- pabilities. The capabilities policy classes differ from scribing the initial prototype. Section 6 covers some each other on the basis of capabilities they possess. related works. Section 7 concludes the paper. Each application is placed in at most one capabilities policy class. The OS resources the application can ac- cess depends on the capabilities associated with that class. We have implemented and tested this concept 2 CAPABILITIES POLICY CLASS on applications deployed under unprivileged (non- root) user entities in isolated (containerized) environ- Our unified access control framework is designed ments. This implementation forms a component of for server-oriented applications deployed in isolated our LPM framework. (containerized) environments dedicated to a single We also propose the concept of communicative application or a small set of them in a security policy classes for communication of applications constrained manner. Most common examples in- that belong to different isolated environments. We clude various system and user oriented services such adapt the generative communication paradigm in- as HTTP web and application servers, DNS server, troduced by Linda programming model (Gelernter, NTP server, various relational database and key-value 1985) which uses the concept of tuple spaces for pro- servers etc. The applications in these environments cess communication. However, the traditional tuple often need access to OS resources. In this section, we spaces lack any security features and also have opera- discuss how to confer such rights to the applications tional limitations. We enhance the original paradigm based on the principle of least privilege. We also dis-

172 Towards Access Control for Isolated Applications

cuss how applications having the access to the same resources are grouped into capabilities policy classes for ease of management and enforcement of the priv- ileges. Such a model implemented as a component of a Linux Policy Machine makes the management and tracking of application-level capabilities feasible at the Linux endpoints. In the Linux environments, the application run- time access control to the underlying OS resources Figure 1: Capabilities Policy Classes. has been traditionally regulated by root privileges which provides all permissions on system and user has to be assessed manually. resources. The applications regulated by root privi- Towards this end, we introduce the notion of a ca- leges run with a special user identifier (UID = 0) that pabilities policy class that is associated with a set of allows them to bypass access control checks. How- Linux capabilities. Each capabilities policy class can ever, giving root permissions to an application vio- have one or more applications. The applications in lates the principle of least privilege and can be mis- such a policy class have all the capabilities associated used. Subsequently, in Linux kernels starting from with this class and can therefore access the same set version 2.1, the root privilege was partitioned into of OS resources as illustrated in Figure 1. Each ap- disjoint capabilities (Linux Developers, 2016). In- plication can belong to at most one capabilities policy stead of providing “root” or “non-root” access, ca- class, but a class can have multiple applications. Note pabilities provide more fine-grained access control – that, two distinct capabilities policy classes will be as- full root permissions no longer need to be granted to sociated with different sets of capabilities. processes accessing some OS resources. For exam- For each new application we first identify the set ple, a web server daemon needs to listen to port 80. of capabilities needed for the execution of its func- Instead of giving this daemon all root permissions, tions. We then check to identify if there is any ca- we can set a capability on the web server binary, like pabilities policy class that has the exact same set of CAP NET BIND SERVICE using which it can open up capabilities. If so, we assign this new application port 80 (and 443 for HTTPS) and listen to it, like to that class. Otherwise, we create a new capabil- intended. The new emerging concept of Linux ap- ities policy class. When the application is deleted, plication containers such as Docker service (Docker we remove the application from the capabilities pol- Developers, 2016) heavily leverages the Linux capa- icy class. When the functionality of the application bilities model. Despite the incorporation of capabili- changes and it needs a different set of capabilities than ties in mainstream Linux and application containers, the class in which it belongs, the application is re- capabilities management in user-space is challenging moved from the capabilities policy class and placed in and is yet to be addressed (Hallyn and Morgan, 2008). a different one. When a policy class contains a single application and the capabilities needed by the appli- Linux capabilities also may provide access to cation change, then we may add/remove capabilities filesystem operations, such as, read/write on data from this policy class. objects. For example, CAP DAC OVERRIDE ca- In order to support the above activities, the fol- pability gives full read and write access to all lowing high-level operations are supported by our ca- files and devices on the system. The capabil- pabilities policy class model: (i) create a capabili- ity CAP DAC READ SEARCH allows an application ties policy class, (ii) add/remove capabilities to/from process to bypass the file read permission checks a policy class, (iii) show capabilities in a policy class, and directory read and execute permissions checks (iv) add/remove applications to/from a capabilities for any file or directory in the system. Cur- policy class, and (v) show/count applications in a ca- rently, there are over 32 capabilities that can be ap- pabilities policy class. Our current implementation of plied to processes and executable files. Examples the LPM supports all of the above operations. The include CAP AUDIT CONTROL, CAP DAC OVERRIDE, sample usage of the model is illustrated in Section 5. CAP IPC LOCK, CAP NET ADMIN etc. Capabilities such as CAP DAC OVERRIDE bestow excessive access rights upon an application. In order to minimize the damage that could be caused by embedding possibly 3 COMMUNICATIVE POLICY malicious code sections into applications, we provide CLASS only the smallest set of capabilities to an application that is needed to accomplish its functions. Such a task Often a group of applications may provide a service

173 SECRYPT 2016 - International Conference on Security and Cryptography

and the individual applications that constitute this group are deployed in isolation as individual service components. Executing the individual service com- ponents in isolated containers has its benefits. If a single containerized application runtime is compro- mised by the attacker, the attack surface is limited in its scope to a single component. This theoretically limits the possibility of disrupting the entire data ser- vice. Moreover, such an approach also simplifies the management and provision of service components. In this model, the individual isolated service com- ponents may need to coordinate and collaborate to provide the service and the various service compo- Figure 2: Flow control of isolated service components nents may not have access to a common centralized database management system or a key-value store for signed to a group are applied uniformly to all mem- the purpose of communication. A simple example bers of that group. In this case, we allow controlled will help illustrate this case. The e-greetings service sharing of private data objects among members of is composed of three service components each run- the communicative policy class via object replication. ning in a separate isolated environment. The service Such a sharing can be very fine-grained and it may be sends personalized greeting e-cards to the e-mail ad- unidirectional – an isolated application can request a dresses of the recipients. Components have only the replica of data object belonging to another isolated minimum privileges needed to accomplish their tasks application but not the other way around. Some ap- and are deployed under separate unprivileged UIDs. plications may require bidirectional access requests Due to isolation properties, those applications cannot where both applications can request replicas of re- write data objects to a shared storage area of the server spective data objects. Such types of possible informa- OS such as /var directory to simplify their interac- tion flow are depicted in Figure 2 where green arrow tion. First component is the HTTP web server that denotes the granted request for a replicated data ob- provides the web interface for the service users to fill ject in the direction of an arrow, while red one with out the greetings card form where a user can choose a cross signifies the forbidden request. Implement- a specific card image and specify the recipient e-mail ing such rules may be non-trivial as isolated environ- address. Four key attributes of the individual greet- ments are non-traversable due to isolation properties. ings order are written into a separate order text file This necessitates proposing alternative communica- – greetings message, sender’s and recipient’s e-mail tion constructs. addresses and the absolute URL to the location of the For instance, we can apply communicative pol- postcard image file. Second component is the e-mail icy class concept to applications deployed in stan- assembling agent (mailman) that processes the order dard chrooted jail that is a variant of isolated (con- file to prepare the greetings e-mail message. Third tainerized) runtime environment. Jail directory is as- component of the service is the actual Mail Trans- signed a distinct UID to utilize existing Linux Dis- fer Agent (MTA) that is responsible for sending the cretionary Acces Control (DAC) mechanism. A ch- individual e-card e-mail message to the greetings re- root on UNIX/Linux operating systems is an opera- cipient. Thus, the mailman component requires con- tion that changes the apparent root directory for the trolled access to the order file prepared by the web current running process and its children. A program server component to create the e-mail message and that is run in such a modified environment cannot the mail sending component, in turn, requires con- name (and therefore normally cannot access) files out- trolled access to individual mail message object. side the designated directory tree. The usage of com- In order to address the requirements of such ap- municative policy classes for various sets of “jailed” plications, we introduce the notion of a communica- applications will naturally allow them to interoperate tive policy class that consists of a group of applica- in a seamless manner without a need to leverage or tions (service components) that reside in different iso- alter traditional DAC scheme of UNIX groups. lated environments and need to collaborate and/or co- The access control policies of a communicative ordinate with each other in order to provide a service policy class specify how the individual applications offering. Our notion of communicative policy class in such a class can request a replica of each others’ is different from the conventional notion of UNIX data objects. Note that, the individual applications groups. In the conventional groups, the privileges as- in the class may have different Linux capabilities –

174 Towards Access Control for Isolated Applications

therefore, the applications may belong to the same The following high-level (business logic) oper- communicative policy class but to different capabili- ations are supported by our communicative policy ties policy classes. Only applications within the same class model as a component of our LPM: (i) cre- communicative class can communicate and therefore ate a communicative policy class (ii) add/remove communication across different communicative pol- applications to/from a communicative policy class icy classes is forbidden. Such a regulation is well- (iii) show/count applications in a communicative pol- suited for multiple data services hosted on a single icy class (iv) add/remove explicit permission for an server instance. The assignment of individual data application to request a replica of a filesystem data service to a separate policy class facilitates the fine- object(s) to/from a communicative policy class (v) en- grained specification of communication policies be- able/disable application coordination with other ap- tween various isolated service components. plication(s) in a communicative policy class. The construct of communicative policy class is de- signed to support the following communication pat- terns among the applications in a single class. 4 COMMUNICATION (i) coordination – often applications acting as a ARCHITECTURE single data service do not require direct access to mu- tual data objects or their replicas but rather need an We now discuss the proposed enforcement architec- exchange of messages to perform coordinated invo- ture for communicative policy class model. cation or maintain collective service component. For instance, one possible deployment scheme for the de- 4.1 IPC Constraints scribed e-greetings data service might add the layer of coordination logic to the interaction between the In general, applications that need to communicate components. For example, if the web component of across machine boundaries use TCP/IP level commu- the service experiences excessive load from user re- nication primitives such as sockets. However, that is quests and generates massive amounts of order files unnecessary for individual applications located on a in a single directory, it can optionally send the coor- single server instance (Minsky et al., 2000). Applica- dination message to the mailman component to indi- tions that need to communicate on a modern UNIX- cate that the request interval for the order files has to like OS may use UNIX domain sockets or similar be decreased from the default 30 seconds to 5 sec- constructs. However, socket level communication is onds. Optionally, additional coordinative information usually complex and requires the development and may be incorporated in the message such as availabil- integration of dedicated network server functional- ity of alternative web server for load-balancing pur- ity into an application. Modern data service com- poses. If the mailman component is capable of re- ponents also prefer information-oriented communica- ceiving and processing such coordination messages, it tion at the level of objects (Cabri et al., 2000). The ne- can, in turn, adjust its e-mail message preparation in- cessity of adequate authentication primitives to prove tervals. Consequently, it can coordinate with the mail application identity may also be non-trivial. More- sending component to indicate faster request times for over, as illustrated in Section 3, many localized appli- the assembled e-mail message objects. cations may require to communicate across isolated Coordination across mutually isolated environ- environments but may not need access to the network ments is problematic. However, if applications belong I/O mechanisms. Thus, more privileges must be con- to a single communicative policy class, it enables the ferred to these applications just for the purpose of col- exchange of coordination messages without reliance laboration or coordination, which violates our princi- on usual UNIX IPC mechanisms that may be unavail- ple of least privilege. able under security constrained conditions. Reliance on kernel-space UNIX IPC primitives (ii) collaboration – components acting as a sin- may also be problematic. First, such an IPC may be gle data service may need to access mutual data or unavailable for security reasons in order to avoid po- runtime file objects to collaborate and perform joint tential malicious inter-application exchange on a sin- or codependent measurements or calculations as il- gle server instance that hosts a large number of iso- lustrated in the e-greetings example and the descrip- lated application services. In other words, IPC may tion of the web caching service presented in Section be disabled on the level of OS kernel (Johnson and 1. Empowering an application with the ability to ob- Troan, 2004). Second, modern applications often re- tain a replica of a data object that belongs to another quire more advanced, higher-level message-oriented application in the same communicative policy class communication that is not offered by the legacy byte- makes such collaboration possible. level IPC constructs. Third, UNIX IPC is bound to

175 SECRYPT 2016 - International Conference on Security and Cryptography

UID/GID access control associations that does not able for interaction and coordination among untrusted provide fine-grained control at the level of individual components. There is also the danger of possible tu- applications (Johnson and Troan, 2004). Therefore ple collisions – as the number of tuples that belongs kernel-space IPC mechanisms do not offer regulated to a large set of divergent applications in a tuple space way of inter-application interaction. increases, there is an increasing chance of acciden- The usage of system-wide user-space IPC frame- tal matching of a tuple that was requested by another works such as D-Bus (Havoc Pennington, 2016) may application. Moreover, the traditional in-memory im- also be problematic. D-Bus is the IPC and Remote plementation of tuple space makes it unsuitable in our Procedure Call (RPC) mechanism that primarily al- current work due to a wide array of possible security lows communication between GUI desktop applica- attacks and memory utilization overheads. Therefore, tions (such as within KDE desktop environment) con- we adapt the tuple space model that will satisfy our currently running on the same machine. D-Bus offers requirements for secure and reliable communication a relatively high-level message-oriented communica- between applications within a single communicative tion between applications on the same machine. How- policy class. Note that, in this adaptation the content- ever, it is not designed to transmit data objects such based nature of retrieval from a tuple space will neces- as logs. Although it is a widely accepted standard for sitate content-based access control approaches (Min- desktop applications, D-Bus may not fit the require- sky et al., 2000). ments of modern server-based data services. In fact, Another problem identified with the RAM-based the main design objective of D-Bus is not message tuple spaces is that it is suitable mainly for a single passing but rather process lifecycle tracking and ser- application with multiple threads that share the same vice discovery (Havoc Pennington, 2016). Moreover, memory address space. In such a simplified deploy- applications have to connect to D-Bus daemon using ment scenario, a global tuple space is easily accessi- UNIX domain sockets or TCP sockets. Before the ble by consumer and producer threads within a single flow of messages begins, two applications must also application. However in the context of our current authenticate themselves which adds extra complex- work we deal with separate data service applications ity layer to the communication. However, the more that do not share the same address space in memory pressing problem is the possibility that user-space D- which makes such a solution unsuitable (Cabri et al., Bus daemon in line with kernel-space IPC may be dis- 2000). For instance, two isolated service components abled on the server for security reasons. More- written in Java cannot access mutual tuple spaces be- over, system-wide communication resources such as cause each component is deployed in a separate Java global for the D-Bus daemon Virtual Machine (JVM) instance. may be inaccessible for applications running in iso- We propose a tuple space calculus that is com- lated environments. pliant with the base model introduced in (Gelernter, 1985) but is applied on dedicated tuple spaces of in- 4.2 Tuple Space Paradigm dividual applications instead of a global space. Our tuple space calculus comprises the following opera- In order to address the complexities introduced in 4.1, tions: (i) create tuple space operation, (ii) delete tu- we propose an alternative approach that can be clas- ple space operation – deletes tuple space only if it is sified as a special case of generative communication empty, (iii) read operation – returns the value of indi- paradigm introduced by Linda programming model vidual tuple without affecting the contents of a tuple (Gelernter, 1985). In this approach, processes com- space, (iv) append operation – adds a tuple without municate indirectly by placing tuples in a tuple space, affecting existing tuples in a tuple space, and (v) take from which other processes can read or remove them. operation – returns a tuple while removing it from a Tuples do not have an address but rather are acces- tuple space. We adhere to the immutability property – sible by matching on content therefore being a type tuples are immutable and applications can either ap- of content-addressable associative memory (Minsky pend or remove tuples in a tuple space without chang- et al., 2000). This programming model allows decou- ing contents of individual tuples. pled interaction between processes separated in time Tuple space is proposed as a persistent filesys- and space: communicating processes need not know tem abstraction with its calculus performed via tu- each other’s identity, nor have a dedicated connection ple space employed by the applications and established between them (Vitek et al., 2003). the LPM. Therefore, this part of the proposed unified The lack of any protection mechanism in the ba- framework is not transparent and the applications may sic model (Vitek et al., 2003; Minsky et al., 2000) need to be modified in order to utilize the tuple space makes the single global shared tuple space unsuit- communication. However, in certain cases that may

176 Towards Access Control for Isolated Applications

not be necessary. For instance, if applications require only limited collaboration, such as periodic requests for replicas of data objects (the case for daily logs), a separate data requester application that employs a tu- ple space library can handle such a task without the need to modify the existing application such as a log analyzer. An application is allowed to perform all the de- scribed operations in its tuple space while LPM is re- stricted to read and append operations only. Note that the take operation is the only manner in which tuples get deleted from a tuple space because the delete tu- ple space operation is allowed only on an empty tuple Figure 3: Tuples Structure. space. The LPM plays a mediating role in the commu- that is an absolute path of an application. (ii) Se- nication between applications. The communication quence Number – indicates the sequence number of takes place through two types of tuples: control tu- a data object chunk that is transported. ASCII objects ples and content tuples. Control tuples can carry mes- in the form of chunks are the primary target of inter- sages for coordination or requests for sharing. Con- application collaboration. (iii) – contains the tent tuples are the mechanism by which data gets chunk of a data object. Content tuples are placed by shared across applications (service components). The the LPM reference monitor into corresponding tuple LPM periodically checks for control tuples in the tu- space of the requesting application that needs to re- ple spaces for applications registered in its database. ceive content. Note that content tuples are designed We have two different types of communication be- for collaboration only. Coordination is performed ex- tween a pair of applications. The first case is where clusively through control tuples. the two applications do not share any data but must communicate with each other in order to coordinate 4.3 Security Aspects activities or computation. The second case is where an application shares its data with another one. We focus on the confidentiality, integrity, and avail- The structure of the tuples is shown in Figure 3. ability issues with respect to tuple space implemen- Control tuples are placed by an application into its tation. Only members of the same communicative tuple space for the purpose of coordination or for re- policy class can coordinate and/or share data. Ex- questing data from other applications. A control tuple tra protection mechanisms are also incorporated for has the following fields: (i) Source ID – indicates an each application’s tuple space. The applications in the absolute path of the application that acts as an appli- same isolated environment have a directory structure cation ID of the communication requester. (ii) Des- within the filesystem for their individual tuple spaces. tination ID – indicates an absolute path of the ap- Each application creates its own tuple space in this plication that acts as an application ID of the com- directory structure. Only the individual application munication recipient. (iii) Type – indicates whether can perform all the operations, namely, create tuple it is a collaborative or coordinative communication. space, delete tuple space, read, append, and take. The (iv) Message – contains the collaborative/coordinative LPM can only perform read and append operations on information. For collaboration it is the request for an the tuple space. Thus, no one other than the applica- absolute path of data object. Coordination message tion itself can remove anything from its tuple space. may be opaque as other entities may be oblivious of Moreover, the confidentiality and integrity are guar- this inter-application communication. It may even be anteed by preventing other applications from directly encrypted to ensure the security and privacy of inter- accessing its tuple space. The directory structure in application coordination efforts. XML or JSON are the filesystem allocated to a given application at any possible formats that can be used for the representa- point of time is contingent upon the needs of the ap- tion of coordination messages. LPM merely shuttles plication, its priority, and its past behavior. Note that, the coordination tuples between respective applica- from the confidentiality standpoint a malicious appli- tions’ spaces and is not aware of their semantics. Con- cation cannot request a replica of a data object that tent tuples are used for sharing data objects across ap- belongs to another application deployed in the sepa- plications and they have the following fields: (i) Des- rate isolated runtime environment unless it is regis- tination ID – indicates the ID of recipient application tered in the policy database containing communica-

177 SECRYPT 2016 - International Conference on Security and Cryptography

tive policies classes of the LPM and has the appropri- ate privileges. Removing it from the associated com- municative policy class will disable the collaboration with other applications. Unrestricted inter-application communication is avoided through the notion of trust between applications that is implicit for components of a single data service. Such components should be logically placed in the same communicative policy class as indicated in Section 3. To further support isolation properties in con- tainerized runtime environments such as application containers the runtime is expected to host only a sin- gle application (service component). For instance, in the isolated runtime environment such as a chroot Figure 4: Linux Policy Machine (LPM) Architecture. jail the chroot directory is populated with all required program files, configuration files, device nodes and shared libraries that are required for the successful service component execution. To prevent the compro- mise of a tuple space, application’s shared libraries (if present) have to be properly audited before inclusion in the runtime environment. Applications may misbehave and cause Denial- of-Service (DOS) attacks by exhausting system re- sources. Fair scheduling mechanism (Belyaev and Ray, 2015) must be implemented to ensure that the LPM serves all the applications in a fair manner. Figure 5: Database Schema of Persistence Layer. Moreover, the tuple space library mechanism has to implement schemes that prevent an application from using all the allocated filesystem space in the direc- arate database server that is prone to potential avail- tory structure of the isolated environment. We an- ability downtimes and security breaches. The LPM ticipate that the LPM must write only a single con- implemented in Java Standard Edition (SE) is de- tent tuple at a given time and the application has to ployed at Linux server endpoints. Figure 4 illustrates take the tuple before a new one is written in its tu- the components of the LPM. These are described be- ple space. Such a strategy avoids overconsumption of low. filesystem space, alleviates disk access loads, and also [User Interface Layer:] This layer provides oper- serves as an acknowledgement mechanism before the ator with command-line interface (CLI) to issue next chunk of the replicated data object is written. commands to manage the framework. [Parser Layer:] This layer parses the user input from the CLI shell and forwards the parsed input to the underlying layers for execution. 5 IMPLEMENTATION AND [Enforcer Layer:] This layer enforces the capabil- DEPLOYMENT ities on the given application using Linux Lib- Cap (Linux Programmer’s Manual, 2016) library We have implemented the prototype of a model for and grants/denies access to OS resources depend- Linux capabilities management using policy classes. ing on the capabilities policy class associated with The model is a component of the LPM that supports the application. The layer also integrates a tuple policy classes abstraction where applications are as- space controller (Minsky et al., 2000) responsible signed to various policy classes depending on the cat- for tuple space operations for the enforcement of egorization criteria. LPM acts as a centralized en- collaboration and coordination of applications in forcement point and reference monitor for the appli- a single communicative policy class. cations running on the Linux server instance. The uni- [Persistence Layer:] This layer provides the Cre- fied framework uses the embedded SQLite database ate/Read/Update/Delete (CRUD) functionality to library to store and manage policy classes abstrac- manage records using embedded database facili- tions and their policies. The usage of embedded ties. The schema of the embedded database for database facility eliminates the dependency on a sep- storing framework policies appears in Figure 5.

178 Towards Access Control for Isolated Applications

The following commands illustrate the use of ca- forcement sub-layer. It includes the benchmarking pabilities policy class model: of various tuple space operations proposed in Sec- SHOW CAPABILITIES tion 4 with the measurements of disk/flash I/O, CPU • SHOW POLICY CLASSES • and RAM utilization for the LPM with integrated tu- CREATE POLICY CLASS P1 ple space controller. We also plan to measure perfor- • network applications policy class ADD POLICY CLASS POLICY P1 CAP NET BIND mance degradation with various sizes of data objects • SERVICE replicated through the LPM reference monitor. ADD POLICY CLASS POLICY P1 CAP CHOWN The initial prototype is publicly available through • MOVE APP TO POLICY CLASS GitHub repository (Belyaev, 2016). We have de- • /home/containers/web-container-100/bin/httpd P1 ployed the LPM on the latest Fedora Server distri- REMOVE POLICY CLASS POLICY P1 bution with applications located in directories under • CAP CHOWN SHOW POLICY CLASS POLICIES P1 distinct UIDs. We successfully tested the function- • SHOW POLICY CLASS APPS P1 ality of policy classes model of managing Linux ca- • pabilities as described in Section 2. Specifically, we The deployment of unified framework in the real- have created several distinct policy classes for these world settings requires a thorough performance eval- application categories: (i) general-purpose applica- uation. The model for capabilities policy classes does tions that do not require any specialized capabilities, not incur any significant performance overheads for (ii) system-level sysadmin management utilities in- the unified framework. This is because its enforce- volving filesystem and related privileges, and (iii) ap- ment is based on the calls to the LibCap library (Linux plications that require access to the OS network stack. Programmer’s Manual, 2016) that essentially updates For instance HTTP Web and Cache servers have been the filesystem capabilities metadata information for deployed under unprivileged UIDs in chrooted jails a process. Such operations do not incur the perfor- with necessary network access capabilities delegated mance overheads because library mediations do not to their binaries by placing the applications in the net- require extra disk I/O aside from the I/O load of the work applications policy class using LPM’s CLI man- base system (Badger et al., 1996). There is also no agement interface. additional memory utilization required aside from the RAM consumption by the LPM itself. However the situation is quite different for the model of communicative policy classes. The en- 6 RELATED WORK forcement is based on the anticipated tuple space paradigm that is known to be quite resource intensive Traditionally, Linux environments supported DAC (Minsky et al., 2000). The performance overheads which allows read, write, and execute permissions for for a memory-resident global shared tuple space are three categories of users, namely, owners, groups, and well known and include memory consumption over- all others for managing access to files and directories heads, efficiency problems with tuple matching at in the user-space. Another type of supported access high speeds and search complexity with a large num- control is based on the Mandatory Access Control ber of divergent tuples present in a single space con- (MAC) designed to enforce system policies: system tinuum (Vitek et al., 2003). Those properties essen- administrators specify policies which are checked via tially pose a limit on a number of tuple objects in a run-time hooks inserted into many places in the oper- given tuple space (Vitek et al., 2003; Minsky et al., ating system’s kernel. For managing access to system 2000; Gelernter, 1985). Taking that into consideration resources, typically superuser privileges are needed. as discussed in Section 4, the design of our tuple space Each file in the system is annotated with a numerical implementation is reliant on the alternative strategy ownership UID. Applications needing access to sys- of the persistent filesystem-based solution with per- tem resources temporarily acquire the privilege of the sonal tuple spaces per application. Performance-wise, superuser. The superuser is assigned UID = 0 – a pro- we rely on OS/hardware filesystem/disk caching (po- cess executing with this UID can bypass all access tentially leveraging fast flash-based storage) and the control rules. This simple model violates the princi- fact that tuple space communication in this work is ple of least privilege. oriented towards infrequent (semi-daily) replication Researchers have proposed Domain and Type En- of medium-sized data objects (not exceeding several forcement (DTE) (Hallyn and Kearns, 2000; Badger Gigabytes) for a finite set of services deployed on et al., 1996) for Linux and UNIX environments. Type a single server instance. Therefore we anticipate to enforcement views a system as a collection of active conduct explicit performance benchmarks as part of entities (subjects) and a collection of passive entities the implementation evaluation of our tuple space en- (objects) (Badger et al., 1996). DTE is designed to

179 SECRYPT 2016 - International Conference on Security and Cryptography

provide MAC to protect a system from subverted su- BAC, our work provides domain-specific expressive peruser processes as the access control is based on policy formulation framework and is implemented in enforceable rule sets. The DTE model, unlike the user-space that allows it to be deployed on any Linux other Linux approaches, avoids the concept of users server system. and only concentrates on applications (Badger et al., The Grsecurity package (GrSecurity Developers, 1996). Our work, like DTE, also concentrates on ac- 2016) is a composition of Linux kernel patches com- cess control requirements of applications and their in- bined with a small set of control programs. The pack- teraction. We also express policies in a human read- age aims to harden known vulnerabilities in the Linux able form. However, our LPM is entirely resident system while paying special attention to privilege es- in user-space in contrast to DTE that offers kernel calation and root exploits. The set of patches provides level solution. Moreover, we target the access con- protection mechanisms for file systems, executables trol requirements necessary for the manageable de- and networks. It does this by placing additional logic ployment of large numbers of localized isolated ap- on the Linux kernel and also alters the kernel’s own plication services under unprivileged UIDs in isolated mechanisms to comply with the desired behaviour. environments, such as chrooted jails and application Grsecurity does not follow any formal model of se- containers. Such environments were outside the scope curity and access control, but emerged as a composi- of DTE. tion of countermeasures against several known weak- Security-Enhanced Linux (SELinux) (Loscocco, nesses, vulnerabilities, or concrete attacks. Conse- 2001; Spencer et al., 1999) allows for the specifi- quently, analysis of the security properties of the var- cation and enforcement of MAC policies at the ker- ious mechanisms is non-trivial. nel level. SELinux uses the Linux Security Modules Application-defined decentralized access control (LSM) (Wright et al., 2002) hooks in the kernel to im- (DCAC) for Linux has been recently proposed by Xu plement its policy. The SELinux architecture is based et al. (Xu et al., 2014) that allows ordinary users to on the Generalized Framework for Access Control perform administrative operations enabling isolation (GFAC) proposed by Abrams (Abrams et al., 1990) and for applications. In DCAC and LaPadula (LaPadula, 1995) and supports multiple applications control their privileges with a mechanism security models. In SELinux the policy server makes implemented and enforced by the operating system, access control decisions and the object managers are but without centralized policy enforcement and ad- responsible for enforcing access control decisions. It ministration. DCAC is configurable on a per-user ba- provides a policy description language for expressing sis only (Xu et al., 2014). The objective of DCAC is various types of policies. SELinux supports the con- decentralization with facilitation of data sharing be- cepts of roles and users but is not intended for en- tween users in a multi-user environment. Our work forcing policies at the level of individual applications. is designed for a different deployment domain – pro- Policy description and configuration in SELinux is vision of access control framework for isolated appli- non-trivial because of the relationships between mul- cations where access control has to be managed and tiple models of SELinux and consequently it is a little enforced by the centralized user-space reference mon- challenging to use (Xu et al., 2014). Our work com- itor at the granularity of individual applications using plements the efforts of SELinux in that it provides ac- expressive high-level policy language without a need cess control for isolated applications in user-space. to modify OS kernel. The Rule Set Based Access Control (RSBAC) (Ott In the realm of enterprise computing applications and Fischer-Hubner,¨ 2001) attempts to bring more ad- running on top of Windows Server infras- vanced access control model to Linux based server tructure the aim is to provide data services (DSs) to systems. RSBAC is an open source security exten- its users. Examples of such services are email, work- sion for current Linux kernels. The kernel based patch flow management, and calendar management. NIST provides high level of security to the Linux kernel and Policy Machine (PM) (Ferraiolo et al., 2014) was pro- operating environment. All RSBAC framework com- posed so that a single access control framework can ponents are hard-linked into the custom-built Linux control and manage the individual capabilities of the kernel. RSBAC supports divergent security policies different DSs. Each DS operates in its own environ- implemented as modules in a single framework. How- ment which has its unique rules for specifying and ever, the framework does not have a mature represen- analyzing access control. The PM tries to provide an tation format to provide a unified way of modeling enterprise operating environment for multi-user base and expressing the policies for all the diverse policy in which policies can be specified and enforced in modules that the framework claims to support. This a uniform manner. The PM follows the attribute- limits its wide-spread adaptability. In contrast to RS- based access control model and can express a wide

180 Towards Access Control for Isolated Applications

range of policies that arise in enterprise applications forcement of is conducted via the and also provides the mechanism for enforcing such centralized LPM reference monitor that regulates the policies. Our research efforts are similar to NIST delivery of messages according to its policies store. PM (Ferraiolo et al., 2014) since it offers the policy Our work also bears resemblance to the Law- management and mediation of data services through Governed Interactions (LGI) proposed by Minsky et a centralized reference monitor. However, our ac- al. (Minsky et al., 2000; Minsky and Ungureanu, cess control goals are different. We do not attempt to 1998) which allows an open group of distributed ac- model user-level policies as done by NIST PM. Our tive entities to interact with each other under a spec- framework, on the other hand, provides the mecha- ified policy called the law of the group. The inter- nism exclusively for controlled inter-application col- application communication in our work is proposed laboration and coordination of localized service com- in the same manner via the tuple space using the ponents across Linux-based isolated runtime environ- tuple space controller integrated in our centralized ments that also regulates access to system resources LPM reference monitor that has complete control based on the principle of least privilege. Note that, over inter-application interaction (Minsky and Un- the importance of such a mechanism that is not cur- gureanu, 1998; Cremonini et al., 2000). rently present in NIST PM is acknowledged by its re- searchers (Ferraiolo et al., 2014). In the mobile devices environment Android In- 7 CONCLUSION AND FUTURE tents (Chin et al., 2011) offers message passing in- frastructure for sandboxed applications; this is sim- WORK ilar in objectives to our tuple space communication paradigm proposed for the enforcement of regulated We have demonstrated how a Linux Policy Machine inter-application communication for isolated service (LPM) can be developed for the Linux environment components using our model of communicative pol- that provides access control specification and enforce- icy classes. Under the Android security model, ment for applications running in isolated environ- each application runs in its own process with a low- ments. The beauty of our system lies in provid- privilege user ID (UID), and applications can only ac- ing a uniform business logic interface to manage ac- cess their own files by default. That is similar to our cess control at both the kernel and application lev- deployment scheme. Our notion of capabilites policy els. We proposed the notion of policy classes to man- classes is similar to Android permissions that are also age policies pertaining to accessing system and ap- based on the principle of least privilege. Permissions plication level resources and demonstrated how inter- are labels, attached to application to declare which application communication can take place through tu- sensitive resources it wants to access. However, An- ple spaces. The initial prototype demonstrates the fea- droid permissions are granted at the user’s discretion sibility of our approach. (Armando et al., 2015). Our server-oriented central- A lot of work remains to be done. We are in the ized framework deterministically enforces capabili- process of developing the tuple space library and the ties and information flow accesses between isolated tuple space controller necessary for the enforcement service components without consent of such compo- of communicative policy class model. Also the Parser nents based on the concept of policy classes. De- and Persistence Layers have to be extended to support spite their default isolation, Android applications can formulation of policies for communicative model. We optionally communicate via message passing. How- also plan to extend this work for distributed settings ever, communication can become an attack vector (Belyaev and Ray, 2015; Singh et al., 2014) where since the Intent messages can be vulnerable to pas- service policies are managed, formulated and updated sive eavesdropping or active denial of service attacks in a centralized location, and then distributed and en- (Chin et al., 2011). We eliminate such a possibil- forced at remote LPM nodes. ity in our proposed communication architecture due to the virtue of tuple space communication that of- fers connectionless inter-application communication ACKNOWLEDGEMENTS as discussed in Section 4. Malicious applications can- not infer on or intercept the inter-application traffic of This work was supported in part by a grant from NIST other services deployed on the same server instance under award no. 70NANB15H264 and by grants from because communication is performed via isolated tu- NSF under award no. CNS 1619641 and IIP 1540041. ple spaces on a filesystem. Moreover, message spoof- ing is also precluded by our architecture since the en-

181 SECRYPT 2016 - International Conference on Security and Cryptography

REFERENCES Linux Developers (2016). Linux Program- mer’s Manual. http://man7.org/linux/man- Abrams, M., Eggers, K., LaPadula, L., and Olson, I. (1990). pages/man7/capabilities.7.html. accessed 12- Generalized Framework for Access Control: An In- March-2016. formal Description. In Proceedings of NCSC. Linux Programmer’s Manual (2016). LIBCAP Manual. Armando, A., Carbone, R., Costa, G., and Merlo, A. (2015). http://man7.org/linux/man-pages/man3/libcap.3.html. Android Permissions Unleashed. In Proceedings of accessed 12-March-2016. IEEE CSF, pages 320–333. IEEE. Loscocco, P. (2001). Integrating Flexible Support for Secu- Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M., rity Policies into the Linux Operating System. In Pro- and Haghighat, S. A. (1996). A Domain and Type ceedings of USENIX ATC, FREENIX Track, page 29. Enforcement UNIX Prototype. Computing Systems, Manual, L. P. (2016). Kernel Namespaces. 9(1):47–83. http://man7.org/linux/man-pages/man7/namespaces. Belyaev, K. (2016). Linux Policy Machine (LPM) 7.html. accessed 12-March-2016. – Managing the Application-Level OS Re- Minsky, N. H., Minsky, Y. M., and Ungureanu, V. (2000). source Control in the Linux Environment. Making Tuple Spaces Safe for Heterogeneous Dis- https://github.com/kirillbelyaev/tinypm/tree/LPM. tributed Systems. In Proceedings of ACM SAC, pages accessed 12-March-2016. 218–226. Belyaev, K. and Ray, I. (2015). Towards Efficient Dissem- Minsky, N. H. and Ungureanu, V. (1998). Unified support ination and Filtering of XML Data Streams. In Pro- for heterogeneous security policies in distributed sys- ceedings of IEEE DASC. tems. In Proc. of USENIX SS, pages 131–142. Cabri, G., Leonardi, L., and Zambonelli, F. (2000). XML n–Logic Ltd. (2016). n-Logic Web Caching Service Dataspaces for Mobile Agent Coordination. In Pro- Provider. http://n-logic.weebly.com/. accessed 12- ceedings of ACM SAC, pages 181–188. ACM. March-2016. Chin, E., Felt, A. P., Greenwood, K., and Wagner, D. Ott, A. and Fischer-Hubner,¨ S. (2001). The Rule Set Based (2011). Analyzing inter-application communication Access Control (RSBAC) Framework for Linux. In in Android. In Proceedings of ACM MobiSys, pages Proceedings of ILK. 239–252. ACM. Singh, J., Bacon, J., and Eyers, D. (2014). Policy enforce- Cremonini, M., Omicini, A., and Zambonelli, F. (2000). ment within emerging distributed, event-based sys- Coordination and access control in open distributed tems. In Proceedings of ACM DEBS, pages 246–255. agent systems: The TuCSoN approach. In Coordina- ACM. tion Languages and Models, pages 99–114. Springer. Spencer, R., Smalley, S., Loscocco, P., Hibler, M., Ander- Docker Developers (2016). What is Docker? sen, D., and Lepreau, J. (1999). The Flask Security https://www.docker.com/what-docker/. accessed Architecture: System Support for Diverse Security 12-March-2016. Policies. In Proceedings of USENIX SS. Ferraiolo, D., Gavrila, S., and Jansen, W. (2014). On the Vitek, J., Bryce, C., and Oriol, M. (2003). Coordinating Unification of Access Control and Data Services. In Processes with Secure Spaces. Science of Computer Proceedings of IEEE IRI, pages 450–457. IEEE. Programming, 46(1):163–193. Gelernter, D. (1985). Generative Communication in Linda. Wright, C., Cowan, C., Smalley, S., Morris, J., and Kroah- ACM TOPLAS, 7(1):80–112. Hartman, G. (2002). Linux Security Modules: Gen- GrSecurity Developers (2016). What is GrSecurity? eral security support for the Linux kernel. In Proceed- https://grsecurity.net. accessed 12-March-2016. ings of USENIX SS, pages 17–31. Hallyn, S. and Kearns, P. (2000). Domain and Type En- Xu, Y., Dunn, A. M., Hofmann, O. S., Lee, M. Z., Mehdi, forcement for Linux. In Proceedings of ALS, pages S. A., and Witchel, E. (2014). Application-Defined 247–260. Decentralized Access Control. In Proceedings of USENIX ATC, pages 395–408. Hallyn, S. E. and Morgan, A. G. (2008). Linux Capabilities: Making them Work. In Proceedings of OLS, page 163. Havoc Pennington, Red Hat, I. (2016). D-Bus Specification. https://dbus.freedesktop.org/doc/dbus- specification.html. accessed 12-March-2016. Johnson, M. K. and Troan, E. W. (2004). Linux Application Development. Addison-Wesley Professional. Krohn, M., Yip, A., Brodsky, M., Cliffer, N., Kaashoek, M. F., Kohler, E., and Morris, R. (2007). Informa- tion flow control for standard OS abstractions. ACM SIGOPS OSR, 41(6):321–334. LaPadula, L. (1995). Rule-Set Modeling of Trusted Com- puter System. In M., A., S., J., and H., P., editors, Information Security: An Integrated Collection of Es- says. IEEE Computer Society Press.

182