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 server operating

system (OS), such as Linux, to handle 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

The advancements in contemporary multi-core CPU

architectures have greatly improved the ability of

modern server operating systems (OS) such as Linux

to deploy a large number of concurrent application

services on a single server instance. The emergence of

application containers (Docker Developers, 2016), in-

troduction of support for kernel namespaces (Manual,

2016) allows a set of loosely coupled service compo-

nents to be executed in isolation from each other and

also from the main operating system. This enables ap-

plication service providers to lower their total cost of

ownership by deploying large numbers of application

services on a single server instance and possibly min-

imize horizontal scaling of applications across multi-

ple nodes.

In conventional UNIX or Linux OS, applications

can be deployed in isolated (containerized) environ-

ments, such as chrooted jails. Such isolated envi-

ronments limit the access of the applications beyond

some designated directory tree and have the potential

to offer enhanced security and performance. How-

ever, no mechanism is provided for controlled com-

munication and sharing of data objects between iso-

lated applications across such environments. A new

type of access control is needed for such isolated ap-

plications for controlling access to OS resources, for

regulating the access requests to the application data

and control objects used for inter-application commu-

nication between service components.

For instance, consider a real-world service deploy-

ment scenario taken from the actual telecom service

provider (n–Logic Ltd., 2016). A Linux server has

three applications, namely, Squid Web Cache Server,

Squid Log Analyzer, and HTTP Web Server, deployed

in three separate isolated environments (chrooted jail

directories), each under a distinct unprivileged user

identiﬁer (UID). Combined all three applications rep-

resent individual components of a single service –

ISP web caching that caches Internet HTTP trafﬁc of

a large customer base to minimize the utilization of

ISP’s Internet backbone. Squid Web Cache Server

component needs access to network socket I/O re-

sources and some advanced networking capabilities

of the Linux kernel in order to operate. However, we

cannot allow this component to run under a super-user

to obtain unrestricted root privileges. Allowing root

access to an application opens possibilities for system

security breaches and can even compromise the entire

OS.

A new mechanism of access control needs to be

enforced for such a component to run under unpriv-

ileged UID but still be able to access necessary OS

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

171

resources. Squid Web Cache Server component gen-

erates daily operational cache logs in its respective

runtime environment. Squid Log Analyzer component

needs to perform data analytics on those operational

log ﬁles on a daily basis. It then creates analytical

results in the form of HTML ﬁles that need to be ac-

cessible by the HTTP Web Server component to be

available through the web browser for administrative

personnel. In such a case, there is a need to access

and share data objects across the applications in dis-

joint containerized environments. Note that, there are

no shared data objects by which such communication

can take place. Usual Inter-Process Communication

(IPC) primitives such as message queues, memory-

mapped ﬁles and shared memory may cause unautho-

rized access or illegal information ﬂow. In fact, IPC

could be disabled to minimize such security breaches.

Moreover, legacy byte-level constructs, such as IPC,

often do not ﬁt under the development framework of

modern applications that operate at the granularity of

higher-level message objects. In such enterprise en-

vironments, a novel paradigm is needed for efﬁcient

and secure communication among isolated processes.

Such coordination and sharing of data must take place

in a controlled manner. Here again, an access control

mechanism is needed that will allow this to happen.

We introduce a new framework referred to as

Linux Policy Machine (and shorten it to just LPM

in the rest of the paper) to address the identiﬁed

challenges. Our LPM allows the management and

enforcement of access to OS resources for individ-

ual applications and it also allows regulated inter-

application communication.

We propose the notion of capabilities policy

classes, each of which is associated with a set of ca-

pabilities. The capabilities policy classes differ from

each other on the basis of capabilities they possess.

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

on applications deployed under unprivileged (non-

root) user entities in isolated (containerized) environ-

ments. This implementation forms a component of

our LPM framework.

We also propose the concept of communicative

policy classes for communication of applications

that belong to different isolated environments. We

adapt the generative communication paradigm in-

troduced by Linda programming model (Gelernter,

1985) which uses the concept of tuple spaces for pro-

cess communication. However, the traditional tuple

spaces lack any security features and also have opera-

tional limitations. We enhance the original paradigm

and also provide rules such that only applications be-

longing to the same communicative policy class can

communicate using this approach. The communica-

tion between applications is mediated through a com-

ponent of the LPM which is allowed limited access to

an application’s tuple space. Consider, for example, a

described web caching data service that is partitioned

into three components, each in a separate chrooted jail

for security purposes. Our LPM allows a regulated

way of coordinating and collaborating among com-

ponents using tuple spaces. Note that, such coordina-

tion and collaboration will be allowed even if each of

the components executes under different system UIDs

and even group identiﬁer (GID).

Our uniform framework provides a coherent busi-

ness logic interface available to administrative per-

sonnel to manage access control for an application

both at the level of OS resources and at the level of

inter-application interaction. Such a centralized LPM

construct that is resident in user-space acts as a refer-

ence monitor for a set of administered data services

deployed on a single Linux server instance. We in-

corporate the access control modelling and decision

control in user-space with robust and expressive per-

sistence layer. This allows high interoperability and

usage of the framework on any general-purpose Linux

OS without a requirement for custom kernel patching

(Krohn et al., 2007).

The rest of the paper is organized as follows.

Section 2 gives a detailed overview of the model to

manage capabilities using policy classes abstraction.

Section 3 describes the proposed model for inter-

application communication across isolated environ-

ments. Section 4 describes the design of the inter-

application communication architecture. Section 5

demonstrates the feasibility of our approach by de-

scribing the initial prototype. Section 6 covers some

related works. Section 7 concludes the paper.

2 CAPABILITIES POLICY CLASS

Our uniﬁed access control framework is designed

for server-oriented applications deployed in isolated

(containerized) environments dedicated to a single

application or a small set of them in a security

constrained manner. Most common examples in-

clude various system and user oriented services such

as HTTP web and application servers, DNS server,

NTP server, various relational database and key-value

servers etc. The applications in these environments

often need access to OS resources. In this section, we

discuss how to confer such rights to the applications

based on the principle of least privilege. We also dis-

SECRYPT 2016 - International Conference on Security and Cryptography

172

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

has been traditionally regulated by root privileges

which provides all permissions on system and user

resources. The applications regulated by root privi-

leges run with a special user identiﬁer (UID = 0) that

allows them to bypass access control checks. How-

ever, giving root permissions to an application vio-

lates the principle of least privilege and can be mis-

used. Subsequently, in Linux kernels starting from

version 2.1, the root privilege was partitioned into

disjoint capabilities (Linux Developers, 2016). In-

stead of providing “root” or “non-root” access, ca-

pabilities provide more ﬁne-grained access control –

full root permissions no longer need to be granted to

processes accessing some OS resources. For exam-

ple, a web server daemon needs to listen to port 80.

Instead of giving this daemon all root permissions,

we can set a capability on the web server binary, like

CAP NET BIND SERVICE using which it can open up

port 80 (and 443 for HTTPS) and listen to it, like

intended. The new emerging concept of Linux ap-

plication containers such as Docker service (Docker

Developers, 2016) heavily leverages the Linux capa-

bilities model. Despite the incorporation of capabili-

ties in mainstream Linux and application containers,

capabilities management in user-space is challenging

and is yet to be addressed (Hallyn and Morgan, 2008).

Linux capabilities also may provide access to

ﬁlesystem operations, such as, read/write on data

objects. For example, CAP DAC OVERRIDE ca-

pability gives full read and write access to all

ﬁles and devices on the system. The capabil-

ity CAP DAC READ SEARCH allows an application

process to bypass the ﬁle read permission checks

and directory read and execute permissions checks

for any ﬁle or directory in the system. Cur-

rently, there are over 32 capabilities that can be ap-

plied to processes and executable ﬁles. Examples

include CAP AUDIT CONTROL, CAP DAC OVERRIDE,

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

malicious code sections into applications, we provide

only the smallest set of capabilities to an application

that is needed to accomplish its functions. Such a task

Figure 1: Capabilities Policy Classes.

has to be assessed manually.

Towards this end, we introduce the notion of a ca-

pabilities policy class that is associated with a set of

Linux capabilities. Each capabilities policy class can

have one or more applications. The applications in

such a policy class have all the capabilities associated

with this class and can therefore access the same set

of OS resources as illustrated in Figure 1. Each ap-

plication can belong to at most one capabilities policy

class, but a class can have multiple applications. Note

that, two distinct capabilities policy classes will be as-

sociated with different sets of capabilities.

For each new application we ﬁrst identify the set

of capabilities needed for the execution of its func-

tions. We then check to identify if there is any ca-

pabilities policy class that has the exact same set of

capabilities. If so, we assign this new application

to that class. Otherwise, we create a new capabil-

ities policy class. When the application is deleted,

we remove the application from the capabilities pol-

icy class. When the functionality of the application

changes and it needs a different set of capabilities than

the class in which it belongs, the application is re-

moved from the capabilities policy class and placed in

a different one. When a policy class contains a single

application and the capabilities needed by the appli-

cation change, then we may add/remove capabilities

from this policy class.

In order to support the above activities, the fol-

lowing high-level operations are supported by our ca-

pabilities policy class model: (i) create a capabili-

ties policy class, (ii) add/remove capabilities to/from

a policy class, (iii) show capabilities in a policy class,

(iv) add/remove applications to/from a capabilities

policy class, and (v) show/count applications in a ca-

pabilities policy class. Our current implementation of

the LPM supports all of the above operations. The

sample usage of the model is illustrated in Section 5.

3 COMMUNICATIVE POLICY

CLASS

Often a group of applications may provide a service

Towards Access Control for Isolated Applications

173

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 beneﬁts. 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 simpliﬁes 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-

nents may not have access to a common centralized

database management system or a key-value store for

the purpose of communication. A simple example

will help illustrate this case. The e-greetings service

is composed of three service components each run-

ning in a separate isolated environment. The service

sends personalized greeting e-cards to the e-mail ad-

dresses of the recipients. Components have only the

minimum privileges needed to accomplish their tasks

and are deployed under separate unprivileged UIDs.

Due to isolation properties, those applications cannot

write data objects to a shared storage area of the server

OS such as /var directory to simplify their interac-

tion. First component is the HTTP web server that

provides the web interface for the service users to ﬁll

out the greetings card form where a user can choose

a speciﬁc card image and specify the recipient e-mail

address. Four key attributes of the individual greet-

ings order are written into a separate order text ﬁle

– greetings message, sender’s and recipient’s e-mail

addresses and the absolute URL to the location of the

postcard image ﬁle. Second component is the e-mail

assembling agent (mailman) that processes the order

ﬁle to prepare the greetings e-mail message. Third

component of the service is the actual Mail Trans-

fer Agent (MTA) that is responsible for sending the

individual e-card e-mail message to the greetings re-

cipient. Thus, the mailman component requires con-

trolled access to the order ﬁle prepared by the web

server component to create the e-mail message and

the mail sending component, in turn, requires con-

trolled access to individual mail message object.

In order to address the requirements of such ap-

plications, we introduce the notion of a communica-

tive policy class that consists of a group of applica-

tions (service components) that reside in different iso-

lated environments and need to collaborate and/or co-

ordinate with each other in order to provide a service

offering. Our notion of communicative policy class

is different from the conventional notion of UNIX

groups. In the conventional groups, the privileges as-

Figure 2: Flow control of isolated service components

signed to a group are applied uniformly to all mem-

bers of that group. In this case, we allow controlled

sharing of private data objects among members of

the communicative policy class via object replication.

Such a sharing can be very ﬁne-grained and it may be

unidirectional – an isolated application can request a

replica of data object belonging to another isolated

application but not the other way around. Some ap-

plications may require bidirectional access requests

where both applications can request replicas of re-

spective data objects. Such types of possible informa-

tion ﬂow are depicted in Figure 2 where green arrow

denotes the granted request for a replicated data ob-

ject in the direction of an arrow, while red one with

a cross signiﬁes the forbidden request. Implement-

ing such rules may be non-trivial as isolated environ-

ments are non-traversable due to isolation properties.

This necessitates proposing alternative communica-

tion constructs.

For instance, we can apply communicative pol-

icy class concept to applications deployed in stan-

dard chrooted jail that is a variant of isolated (con-

tainerized) runtime environment. Jail directory is as-

signed a distinct UID to utilize existing Linux Dis-

cretionary Acces Control (DAC) mechanism. A ch-

root on UNIX/Linux operating systems is an opera-

tion that changes the apparent root directory for the

current running process and its children. A program

that is run in such a modiﬁed environment cannot

name (and therefore normally cannot access) ﬁles out-

side the designated directory tree. The usage of com-

municative policy classes for various sets of “jailed”

applications will naturally allow them to interoperate

in a seamless manner without a need to leverage or

alter traditional DAC scheme of UNIX groups.

The access control policies of a communicative

policy class specify how the individual applications

in such a class can request a replica of each others’

data objects. Note that, the individual applications

in the class may have different Linux capabilities –

SECRYPT 2016 - International Conference on Security and Cryptography

174

therefore, the applications may belong to the same

communicative policy class but to different capabili-

ties policy classes. Only applications within the same

communicative class can communicate and therefore

communication across different communicative pol-

icy classes is forbidden. Such a regulation is well-

suited for multiple data services hosted on a single

server instance. The assignment of individual data

service to a separate policy class facilitates the ﬁne-

grained speciﬁcation of communication policies be-

tween various isolated service components.

The construct of communicative policy class is de-

signed to support the following communication pat-

terns among the applications in a single class.

(i) coordination – often applications acting as a

single data service do not require direct access to mu-

tual data objects or their replicas but rather need an

exchange of messages to perform coordinated invo-

cation or maintain collective service component. For

instance, one possible deployment scheme for the de-

scribed e-greetings data service might add the layer

of coordination logic to the interaction between the

components. For example, if the web component of

the service experiences excessive load from user re-

quests and generates massive amounts of order ﬁles

in a single directory, it can optionally send the coor-

dination message to the mailman component to indi-

cate that the request interval for the order ﬁles has to

be decreased from the default 30 seconds to 5 sec-

onds. Optionally, additional coordinative information

may be incorporated in the message such as availabil-

ity of alternative web server for load-balancing pur-

poses. If the mailman component is capable of re-

ceiving and processing such coordination messages, it

can, in turn, adjust its e-mail message preparation in-

tervals. Consequently, it can coordinate with the mail

sending component to indicate faster request times for

the assembled e-mail message objects.

Coordination across mutually isolated environ-

ments is problematic. However, if applications belong

to a single communicative policy class, it enables the

exchange of coordination messages without reliance

on usual UNIX IPC mechanisms that may be unavail-

able under security constrained conditions.

(ii) collaboration – components acting as a sin-

gle data service may need to access mutual data or

runtime ﬁle objects to collaborate and perform joint

or codependent measurements or calculations as il-

lustrated in the e-greetings example and the descrip-

tion of the web caching service presented in Section

1. Empowering an application with the ability to ob-

tain a replica of a data object that belongs to another

application in the same communicative policy class

makes such collaboration possible.

The following high-level (business logic) oper-

ations are supported by our communicative policy

class model as a component of our LPM: (i) cre-

ate a communicative policy class (ii) add/remove

applications to/from a communicative policy class

(iii) show/count applications in a communicative pol-

icy class (iv) add/remove explicit permission for an

application to request a replica of a ﬁlesystem data

object(s) to/from a communicative policy class (v) en-

able/disable application coordination with other ap-

plication(s) in a communicative policy class.

4 COMMUNICATION

ARCHITECTURE

We now discuss the proposed enforcement architec-

ture for communicative policy class model.

4.1 IPC Constraints

In general, applications that need to communicate

across machine boundaries use TCP/IP level commu-

nication primitives such as sockets. However, that is

unnecessary for individual applications located on a

single server instance (Minsky et al., 2000). Applica-

tions that need to communicate on a modern UNIX-

like OS may use UNIX domain sockets or similar

constructs. However, socket level communication is

usually complex and requires the development and

integration of dedicated network server functional-

ity into an application. Modern data service com-

ponents also prefer information-oriented communica-

tion at the level of objects (Cabri et al., 2000). The ne-

cessity of adequate authentication primitives to prove

application identity may also be non-trivial. More-

over, as illustrated in Section 3, many localized appli-

cations may require to communicate across isolated

environments but may not need access to the network

I/O mechanisms. Thus, more privileges must be con-

ferred to these applications just for the purpose of col-

laboration or coordination, which violates our princi-

ple of least privilege.

Reliance on kernel-space UNIX IPC primitives

may also be problematic. First, such an IPC may be

unavailable for security reasons in order to avoid po-

tential malicious inter-application exchange on a sin-

gle server instance that hosts a large number of iso-

lated application services. In other words, IPC may

be disabled on the level of OS kernel (Johnson and

Troan, 2004). Second, modern applications often re-

quire more advanced, higher-level message-oriented

communication that is not offered by the legacy byte-

level IPC constructs. Third, UNIX IPC is bound to

Towards Access Control for Isolated Applications

175

UID/GID access control associations that does not

provide ﬁne-grained control at the level of individual

applications (Johnson and Troan, 2004). Therefore

kernel-space IPC mechanisms do not offer regulated

way of inter-application interaction.

The usage of system-wide user-space IPC frame-

works such as D-Bus (Havoc Pennington, 2016) may

also be problematic. D-Bus is the IPC and Remote

Procedure Call (RPC) mechanism that primarily al-

lows communication between GUI desktop applica-

tions (such as within KDE desktop environment) con-

currently running on the same machine. D-Bus offers

a relatively high-level message-oriented communica-

tion between applications on the same machine. How-

ever, it is not designed to transmit data objects such

as logs. Although it is a widely accepted standard for

desktop applications, D-Bus may not ﬁt the require-

ments of modern server-based data services. In fact,

the main design objective of D-Bus is not message

passing but rather process lifecycle tracking and ser-

vice discovery (Havoc Pennington, 2016). Moreover,

applications have to connect to D-Bus daemon using

UNIX domain sockets or TCP sockets. Before the

ﬂow of messages begins, two applications must also

authenticate themselves which adds extra complex-

ity layer to the communication. However, the more

pressing problem is the possibility that user-space D-

Bus daemon in line with kernel-space IPC may be dis-

abled on the server node for security reasons. More-

over, system-wide communication resources such as

global UNIX domain socket for the D-Bus daemon

may be inaccessible for applications running in iso-

lated environments.

4.2 Tuple Space Paradigm

In order to address the complexities introduced in 4.1,

we propose an alternative approach that can be clas-

siﬁed as a special case of generative communication

paradigm introduced by Linda programming model

(Gelernter, 1985). In this approach, processes com-

municate indirectly by placing tuples in a tuple space,

from which other processes can read or remove them.

Tuples do not have an address but rather are acces-

sible by matching on content therefore being a type

of content-addressable associative memory (Minsky

et al., 2000). This programming model allows decou-

pled interaction between processes separated in time

and space: communicating processes need not know

each other’s identity, nor have a dedicated connection

established between them (Vitek et al., 2003).

The lack of any protection mechanism in the ba-

sic model (Vitek et al., 2003; Minsky et al., 2000)

makes the single global shared tuple space unsuit-

able for interaction and coordination among untrusted

components. There is also the danger of possible tu-

ple collisions – as the number of tuples that belongs

to a large set of divergent applications in a tuple space

increases, there is an increasing chance of acciden-

tal matching of a tuple that was requested by another

application. Moreover, the traditional in-memory im-

plementation of tuple space makes it unsuitable in our

current work due to a wide array of possible security

attacks and memory utilization overheads. Therefore,

we adapt the tuple space model that will satisfy our

requirements for secure and reliable communication

between applications within a single communicative

policy class. Note that, in this adaptation the content-

based nature of retrieval from a tuple space will neces-

sitate content-based access control approaches (Min-

sky et al., 2000).

Another problem identiﬁed with the RAM-based

tuple spaces is that it is suitable mainly for a single

application with multiple threads that share the same

memory address space. In such a simpliﬁed deploy-

ment scenario, a global tuple space is easily accessi-

ble by consumer and producer threads within a single

application. However in the context of our current

work we deal with separate data service applications

that do not share the same address space in memory

which makes such a solution unsuitable (Cabri et al.,

2000). For instance, two isolated service components

written in Java cannot access mutual tuple spaces be-

cause each component is deployed in a separate Java

Virtual Machine (JVM) instance.

We propose a tuple space calculus that is com-

pliant with the base model introduced in (Gelernter,

1985) but is applied on dedicated tuple spaces of in-

dividual applications instead of a global space. Our

tuple space calculus comprises the following opera-

tions: (i) create tuple space operation, (ii) delete tu-

ple space operation – deletes tuple space only if it is

empty, (iii) read operation – returns the value of indi-

vidual tuple without affecting the contents of a tuple

space, (iv) append operation – adds a tuple without

affecting existing tuples in a tuple space, and (v) take

operation – returns a tuple while removing it from a

tuple space. We adhere to the immutability property –

tuples are immutable and applications can either ap-

pend or remove tuples in a tuple space without chang-

ing contents of individual tuples.

Tuple space is proposed as a persistent ﬁlesys-

tem abstraction with its calculus performed via tu-

ple space library employed by the applications and

the LPM. Therefore, this part of the proposed uniﬁed

framework is not transparent and the applications may

need to be modiﬁed in order to utilize the tuple space

communication. However, in certain cases that may

SECRYPT 2016 - International Conference on Security and Cryptography

176

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

space.

The LPM plays a mediating role in the commu-

nication between applications. The communication

takes place through two types of tuples: control tu-

ples and content tuples. Control tuples can carry mes-

sages for coordination or requests for sharing. Con-

tent tuples are the mechanism by which data gets

shared across applications (service components). The

LPM periodically checks for control tuples in the tu-

ple spaces for applications registered in its database.

We have two different types of communication be-

tween a pair of applications. The ﬁrst case is where

the two applications do not share any data but must

communicate with each other in order to coordinate

activities or computation. The second case is where

an application shares its data with another one.

The structure of the tuples is shown in Figure 3.

Control tuples are placed by an application into its

tuple space for the purpose of coordination or for re-

questing data from other applications. A control tuple

has the following ﬁelds: (i) Source ID – indicates an

absolute path of the application that acts as an appli-

cation ID of the communication requester. (ii) Des-

tination ID – indicates an absolute path of the ap-

plication that acts as an application ID of the com-

munication recipient. (iii) Type – indicates whether

it is a collaborative or coordinative communication.

(iv) Message – contains the collaborative/coordinative

information. For collaboration it is the request for an

absolute path of data object. Coordination message

may be opaque as other entities may be oblivious of

this inter-application communication. It may even be

encrypted to ensure the security and privacy of inter-

application coordination efforts. XML or JSON are

possible formats that can be used for the representa-

tion of coordination messages. LPM merely shuttles

the coordination tuples between respective applica-

tions’ spaces and is not aware of their semantics. Con-

tent tuples are used for sharing data objects across ap-

plications and they have the following ﬁelds: (i) Des-

tination ID – indicates the ID of recipient application

Figure 3: Tuples Structure.

that is an absolute path of an application. (ii) Se-

quence Number – indicates the sequence number of

a data object chunk that is transported. ASCII objects

in the form of chunks are the primary target of inter-

application collaboration. (iii) Payload – contains the

chunk of a data object. Content tuples are placed by

the LPM reference monitor into corresponding tuple

space of the requesting application that needs to re-

ceive content. Note that content tuples are designed

for collaboration only. Coordination is performed ex-

clusively through control tuples.

4.3 Security Aspects

We focus on the conﬁdentiality, integrity, and avail-

ability issues with respect to tuple space implemen-

tation. Only members of the same communicative

policy class can coordinate and/or share data. Ex-

tra protection mechanisms are also incorporated for

each application’s tuple space. The applications in the

same isolated environment have a directory structure

within the ﬁlesystem for their individual tuple spaces.

Each application creates its own tuple space in this

directory structure. Only the individual application

can perform all the operations, namely, create tuple

space, delete tuple space , read, append, and take. The

LPM can only perform read and append operations on

the tuple space. Thus, no one other than the applica-

tion itself can remove anything from its tuple space.

Moreover, the conﬁdentiality and integrity are guar-

anteed by preventing other applications from directly

accessing its tuple space. The directory structure in

the ﬁlesystem allocated to a given application at any

point of time is contingent upon the needs of the ap-

plication, its priority, and its past behavior. Note that,

from the conﬁdentiality standpoint a malicious appli-

cation cannot request a replica of a data object that

belongs to another application deployed in the sepa-

rate isolated runtime environment unless it is regis-

tered in the policy database containing communica-

Towards Access Control for Isolated Applications

177

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

jail the chroot directory is populated with all required

program ﬁles, conﬁguration ﬁles, 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.

Moreover, the tuple space library mechanism has to

implement schemes that prevent an application from

using all the allocated ﬁlesystem space in the direc-

tory structure of the isolated environment. We an-

ticipate that the LPM must write only a single con-

tent tuple at a given time and the application has to

take the tuple before a new one is written in its tu-

ple space. Such a strategy avoids overconsumption of

ﬁlesystem space, alleviates disk access loads, and also

serves as an acknowledgement mechanism before the

next chunk of the replicated data object is written.

5 IMPLEMENTATION AND

DEPLOYMENT

We have implemented the prototype of a model for

Linux capabilities management using policy classes.

The model is a component of the LPM that supports

policy classes abstraction where applications are as-

signed to various policy classes depending on the cat-

egorization criteria. LPM acts as a centralized en-

forcement point and reference monitor for the appli-

cations running on the Linux server instance. The uni-

ﬁed framework uses the embedded SQLite database

library to store and manage policy classes abstrac-

tions and their policies. The usage of embedded

database facility eliminates the dependency on a sep-

Figure 4: Linux Policy Machine (LPM) Architecture.

Figure 5: Database Schema of Persistence Layer.

arate database server that is prone to potential avail-

ability downtimes and security breaches. The LPM

implemented in Java Standard Edition (SE) is de-

ployed at Linux server endpoints. Figure 4 illustrates

the components of the LPM. These are described be-

low.

[User Interface Layer:] This layer provides oper-

ator with command-line interface (CLI) to issue

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.

[Enforcer Layer:] This layer enforces the capabil-

ities on the given application using Linux Lib-

Cap (Linux Programmer’s Manual, 2016) library

and grants/denies access to OS resources depend-

ing on the capabilities policy class associated with

the application. The layer also integrates a tuple

space controller (Minsky et al., 2000) responsible

for tuple space operations for the enforcement of

collaboration and coordination of applications in

a single communicative policy class.

[Persistence Layer:] This layer provides the Cre-

ate/Read/Update/Delete (CRUD) functionality to

manage records using embedded database facili-

ties. The schema of the embedded database for

storing framework policies appears in Figure 5.

SECRYPT 2016 - International Conference on Security and Cryptography

178

The following commands illustrate the use of ca-

pabilities policy class model:

• SHOW CAPABILITIES

• SHOW POLICY CLASSES

• CREATE POLICY CLASS P1

network applications policy class

• ADD POLICY CLASS POLICY P1 CAP NET BIND

SERVICE

• ADD POLICY CLASS POLICY P1 CAP CHOWN

• MOVE APP TO POLICY CLASS

/home/containers/web-container-100/bin/httpd P1

• REMOVE POLICY CLASS POLICY P1

CAP CHOWN

• SHOW POLICY CLASS POLICIES P1

• SHOW POLICY CLASS APPS P1

The deployment of uniﬁed framework in the real-

world settings requires a thorough performance eval-

uation. The model for capabilities policy classes does

not incur any signiﬁcant performance overheads for

the uniﬁed framework. This is because its enforce-

ment is based on the calls to the LibCap library (Linux

Programmer’s Manual, 2016) that essentially updates

the ﬁlesystem capabilities metadata information for

a process. Such operations do not incur the perfor-

mance overheads because library mediations do not

require extra disk I/O aside from the I/O load of the

base system (Badger et al., 1996). There is also no

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-

forcement is based on the anticipated tuple space

paradigm that is known to be quite resource intensive

(Minsky et al., 2000). The performance overheads

for a memory-resident global shared tuple space are

well known and include memory consumption over-

heads, efﬁciency problems with tuple matching at

high speeds and search complexity with a large num-

ber of divergent tuples present in a single space con-

tinuum (Vitek et al., 2003). Those properties essen-

tially pose a limit on a number of tuple objects in a

given tuple space (Vitek et al., 2003; Minsky et al.,

2000; Gelernter, 1985). Taking that into consideration

as discussed in Section 4, the design of our tuple space

implementation is reliant on the alternative strategy

of the persistent ﬁlesystem-based solution with per-

sonal tuple spaces per application. Performance-wise,

we rely on OS/hardware ﬁlesystem/disk caching (po-

tentially leveraging fast ﬂash-based storage) and the

fact that tuple space communication in this work is

oriented towards infrequent (semi-daily) replication

of medium-sized data objects (not exceeding several

Gigabytes) for a ﬁnite set of services deployed on

a single server instance. Therefore we anticipate to

conduct explicit performance benchmarks as part of

the implementation evaluation of our tuple space en-

forcement sub-layer. It includes the benchmarking

of various tuple space operations proposed in Sec-

tion 4 with the measurements of disk/ﬂash I/O, CPU

and RAM utilization for the LPM with integrated tu-

ple space controller. We also plan to measure perfor-

mance degradation with various sizes of data objects

replicated through the LPM reference monitor.

The initial prototype is publicly available through

GitHub repository (Belyaev, 2016). We have de-

ployed the LPM on the latest Fedora Server distri-

bution with applications located in directories under

distinct UIDs. We successfully tested the function-

ality of policy classes model of managing Linux ca-

pabilities as described in Section 2. Speciﬁcally, we

have created several distinct policy classes for these

application categories: (i) general-purpose applica-

tions that do not require any specialized capabilities,

(ii) system-level sysadmin management utilities in-

volving ﬁlesystem and related privileges, and (iii) ap-

plications that require access to the OS network stack.

For instance HTTP Web and Cache servers have been

deployed under unprivileged UIDs in chrooted jails

with necessary network access capabilities delegated

to their binaries by placing the applications in the net-

work applications policy class using LPM’s CLI man-

agement interface.

6 RELATED WORK

Traditionally, Linux environments supported DAC

which allows read, write, and execute permissions for

three categories of users, namely, owners, groups, and

all others for managing access to ﬁles and directories

in the user-space. Another type of supported access

control is based on the Mandatory Access Control

(MAC) designed to enforce system policies: system

administrators specify policies which are checked via

run-time hooks inserted into many places in the oper-

ating system’s kernel. For managing access to system

resources, typically superuser privileges are needed.

Each ﬁle in the system is annotated with a numerical

ownership UID. Applications needing access to sys-

tem resources temporarily acquire the privilege of the

superuser. The superuser is assigned UID = 0 – a pro-

cess executing with this UID can bypass all access

control rules. This simple model violates the princi-

ple of least privilege.

Researchers have proposed Domain and Type En-

forcement (DTE) (Hallyn and Kearns, 2000; Badger

et al., 1996) for Linux and UNIX environments. Type

enforcement views a system as a collection of active

entities (subjects) and a collection of passive entities

(objects) (Badger et al., 1996). DTE is designed to

Towards Access Control for Isolated Applications

179

provide MAC to protect a system from subverted su-

peruser processes as the access control is based on

enforceable rule sets. The DTE model, unlike the

other Linux approaches, avoids the concept of users

and only concentrates on applications (Badger et al.,

1996). Our work, like DTE, also concentrates on ac-

cess control requirements of applications and their in-

teraction. We also express policies in a human read-

able form. However, our LPM is entirely resident

in user-space in contrast to DTE that offers kernel

level solution. Moreover, we target the access con-

trol requirements necessary for the manageable de-

ployment of large numbers of localized isolated ap-

plication services under unprivileged UIDs in isolated

environments, such as chrooted jails and application

containers. Such environments were outside the scope

of DTE.

Security-Enhanced Linux (SELinux) (Loscocco,

2001; Spencer et al., 1999) allows for the speciﬁ-

cation and enforcement of MAC policies at the ker-

nel level. SELinux uses the Linux Security Modules

(LSM) (Wright et al., 2002) hooks in the kernel to im-

plement its policy. The SELinux architecture is based

on the Generalized Framework for Access Control

(GFAC) proposed by Abrams (Abrams et al., 1990)

and LaPadula (LaPadula, 1995) and supports multiple

security models. In SELinux the policy server makes

access control decisions and the object managers are

responsible for enforcing access control decisions. It

provides a policy description language for expressing

various types of policies. SELinux supports the con-

cepts of roles and users but is not intended for en-

forcing policies at the level of individual applications.

Policy description and conﬁguration in SELinux is

non-trivial because of the relationships between mul-

tiple models of SELinux and consequently it is a little

challenging to use (Xu et al., 2014). Our work com-

plements the efforts of SELinux in that it provides ac-

cess control for isolated applications in user-space.

The Rule Set Based Access Control (RSBAC) (Ott

and Fischer-H

ubner, 2001) attempts to bring more ad-

vanced access control model to Linux based server

systems. RSBAC is an open source security exten-

sion for current Linux kernels. The kernel based patch

provides high level of security to the Linux kernel and

operating environment. All RSBAC framework com-

ponents are hard-linked into the custom-built Linux

kernel. RSBAC supports divergent security policies

implemented as modules in a single framework. How-

ever, the framework does not have a mature represen-

tation format to provide a uniﬁed way of modeling

and expressing the policies for all the diverse policy

modules that the framework claims to support. This

limits its wide-spread adaptability. In contrast to RS-

BAC, our work provides domain-speciﬁc expressive

policy formulation framework and is implemented in

user-space that allows it to be deployed on any Linux

server system.

The Grsecurity package (GrSecurity Developers,

2016) is a composition of Linux kernel patches com-

bined with a small set of control programs. The pack-

age aims to harden known vulnerabilities in the Linux

system while paying special attention to privilege es-

calation and root exploits. The set of patches provides

protection mechanisms for ﬁle systems, executables

and networks. It does this by placing additional logic

on the Linux kernel and also alters the kernel’s own

mechanisms to comply with the desired behaviour.

Grsecurity does not follow any formal model of se-

curity and access control, but emerged as a composi-

tion of countermeasures against several known weak-

nesses, vulnerabilities, or concrete attacks. Conse-

quently, analysis of the security properties of the var-

ious mechanisms is non-trivial.

Application-deﬁned decentralized access control

(DCAC) for Linux has been recently proposed by Xu

et al. (Xu et al., 2014) that allows ordinary users to

perform administrative operations enabling isolation

and privilege separation for applications. In DCAC

applications control their privileges with a mechanism

implemented and enforced by the operating system,

but without centralized policy enforcement and ad-

ministration. DCAC is conﬁgurable on a per-user ba-

sis only (Xu et al., 2014). The objective of DCAC is

decentralization with facilitation of data sharing be-

tween users in a multi-user environment. Our work

is designed for a different deployment domain – pro-

vision of access control framework for isolated appli-

cations where access control has to be managed and

enforced by the centralized user-space reference mon-

itor at the granularity of individual applications using

expressive high-level policy language without a need

to modify OS kernel.

In the realm of enterprise computing applications

running on top of Microsoft Windows Server infras-

tructure the aim is to provide data services (DSs) to

its users. Examples of such services are email, work-

ﬂow management, and calendar management. NIST

Policy Machine (PM) (Ferraiolo et al., 2014) was pro-

posed so that a single access control framework can

control and manage the individual capabilities of the

different DSs. Each DS operates in its own environ-

ment which has its unique rules for specifying and

analyzing access control. The PM tries to provide an

enterprise operating environment for multi-user base

in which policies can be speciﬁed and enforced in

a uniform manner. The PM follows the attribute-

based access control model and can express a wide

SECRYPT 2016 - International Conference on Security and Cryptography

180

range of policies that arise in enterprise applications

and also provides the mechanism for enforcing such

policies. Our research efforts are similar to NIST

PM (Ferraiolo et al., 2014) since it offers the policy

management and mediation of data services through

a centralized reference monitor. However, our ac-

cess control goals are different. We do not attempt to

model user-level policies as done by NIST PM. Our

framework, on the other hand, provides the mecha-

nism exclusively for controlled inter-application col-

laboration and coordination of localized service com-

ponents across Linux-based isolated runtime environ-

ments that also regulates access to system resources

based on the principle of least privilege. Note that,

the importance of such a mechanism that is not cur-

rently present in NIST PM is acknowledged by its re-

searchers (Ferraiolo et al., 2014).

In the mobile devices environment Android In-

tents (Chin et al., 2011) offers message passing in-

frastructure for sandboxed applications; this is sim-

ilar in objectives to our tuple space communication

paradigm proposed for the enforcement of regulated

inter-application communication for isolated service

components using our model of communicative pol-

icy classes. Under the Android security model,

each application runs in its own process with a low-

privilege user ID (UID), and applications can only ac-

cess their own ﬁles by default. That is similar to our

deployment scheme. Our notion of capabilites policy

classes is similar to Android permissions that are also

based on the principle of least privilege. Permissions

are labels, attached to application to declare which

sensitive resources it wants to access. However, An-

droid permissions are granted at the user’s discretion

(Armando et al., 2015). Our server-oriented central-

ized framework deterministically enforces capabili-

ties and information ﬂow accesses between isolated

service components without consent of such compo-

nents based on the concept of policy classes. De-

spite their default isolation, Android applications can

optionally communicate via message passing. How-

ever, communication can become an attack vector

since the Intent messages can be vulnerable to pas-

sive eavesdropping or active denial of service attacks

(Chin et al., 2011). We eliminate such a possibil-

ity in our proposed communication architecture due

to the virtue of tuple space communication that of-

fers connectionless inter-application communication

as discussed in Section 4. Malicious applications can-

not infer on or intercept the inter-application trafﬁc of

other services deployed on the same server instance

because communication is performed via isolated tu-

ple spaces on a ﬁlesystem. Moreover, message spoof-

ing is also precluded by our architecture since the en-

forcement of message passing is conducted via the

centralized LPM reference monitor that regulates the

delivery of messages according to its policies store.

Our work also bears resemblance to the Law-

Governed Interactions (LGI) proposed by Minsky et

al. (Minsky et al., 2000; Minsky and Ungureanu,

1998) which allows an open group of distributed ac-

tive entities to interact with each other under a spec-

iﬁed policy called the law of the group. The inter-

application communication in our work is proposed

in the same manner via the tuple space using the

tuple space controller integrated in our centralized

LPM reference monitor that has complete control

over inter-application interaction (Minsky and Un-

gureanu, 1998; Cremonini et al., 2000).

7 CONCLUSION AND FUTURE

WORK

We have demonstrated how a Linux Policy Machine

(LPM) can be developed for the Linux environment

that provides access control speciﬁcation and enforce-

ment for applications running in isolated environ-

ments. The beauty of our system lies in provid-

ing a uniform business logic interface to manage ac-

cess control at both the kernel and application lev-

els. We proposed the notion of policy classes to man-

age policies pertaining to accessing system and ap-

plication level resources and demonstrated how inter-

application communication can take place through tu-

ple spaces. The initial prototype demonstrates the fea-

sibility of our approach.

A lot of work remains to be done. We are in the

process of developing the tuple space library and the

tuple space controller necessary for the enforcement

of communicative policy class model. Also the Parser

and Persistence Layers have to be extended to support

formulation of policies for communicative model. We

also plan to extend this work for distributed settings

(Belyaev and Ray, 2015; Singh et al., 2014) where

service policies are managed, formulated and updated

in a centralized location, and then distributed and en-

forced at remote LPM nodes.

ACKNOWLEDGEMENTS

This work was supported in part by a grant from NIST

under award no. 70NANB15H264 and by grants from

NSF under award no. CNS 1619641 and IIP 1540041.

Towards Access Control for Isolated Applications

181

REFERENCES

Abrams, M., Eggers, K., LaPadula, L., and Olson, I. (1990).

Generalized Framework for Access Control: An In-

formal Description. In Proceedings of NCSC.

Armando, A., Carbone, R., Costa, G., and Merlo, A. (2015).

Android Permissions Unleashed. In Proceedings of

IEEE CSF, pages 320–333. IEEE.

Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M.,

and Haghighat, S. A. (1996). A Domain and Type

Enforcement UNIX Prototype. Computing Systems,

9(1):47–83.

Belyaev, K. (2016). Linux Policy Machine (LPM)

– Managing the Application-Level OS Re-

source Control in the Linux Environment.

https://github.com/kirillbelyaev/tinypm/tree/LPM.

accessed 12-March-2016.

Belyaev, K. and Ray, I. (2015). Towards Efﬁcient Dissem-

ination and Filtering of XML Data Streams. In Pro-

ceedings of IEEE DASC.

Cabri, G., Leonardi, L., and Zambonelli, F. (2000). XML

Dataspaces for Mobile Agent Coordination. In Pro-

ceedings of ACM SAC, pages 181–188. ACM.

Chin, E., Felt, A. P., Greenwood, K., and Wagner, D.

(2011). Analyzing inter-application communication

in Android. In Proceedings of ACM MobiSys, pages

239–252. ACM.

Cremonini, M., Omicini, A., and Zambonelli, F. (2000).

Coordination and access control in open distributed

agent systems: The TuCSoN approach. In Coordina-

tion Languages and Models, pages 99–114. Springer.

Docker Developers (2016). What is Docker?

https://www.docker.com/what-docker/. accessed

12-March-2016.

Ferraiolo, D., Gavrila, S., and Jansen, W. (2014). On the

Uniﬁcation of Access Control and Data Services. In

Proceedings of IEEE IRI, pages 450–457. IEEE.

Gelernter, D. (1985). Generative Communication in Linda.

ACM TOPLAS, 7(1):80–112.

GrSecurity Developers (2016). What is GrSecurity?

https://grsecurity.net. accessed 12-March-2016.

Hallyn, S. and Kearns, P. (2000). Domain and Type En-

forcement for Linux. In Proceedings of ALS, pages

247–260.

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

Speciﬁcation. https://dbus.freedesktop.org/doc/dbus-

speciﬁcation.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 ﬂow 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.

Linux Developers (2016). Linux Program-

mer’s Manual. http://man7.org/linux/man-

pages/man7/capabilities.7.html. accessed 12-

March-2016.

Linux Programmer’s Manual (2016). LIBCAP Manual.

http://man7.org/linux/man-pages/man3/libcap.3.html.

accessed 12-March-2016.

Loscocco, P. (2001). Integrating Flexible Support for Secu-

rity Policies into the Linux Operating System. In Pro-

ceedings of USENIX ATC, FREENIX Track, page 29.

Manual, L. P. (2016). Kernel Namespaces.

http://man7.org/linux/man-pages/man7/namespaces.

7.html. accessed 12-March-2016.

Minsky, N. H., Minsky, Y. M., and Ungureanu, V. (2000).

Making Tuple Spaces Safe for Heterogeneous Dis-

tributed Systems. In Proceedings of ACM SAC, pages

218–226.

Minsky, N. H. and Ungureanu, V. (1998). Uniﬁed support

for heterogeneous security policies in distributed sys-

tems. In Proc. of USENIX SS, pages 131–142.

n–Logic Ltd. (2016). n-Logic Web Caching Service

Provider. http://n-logic.weebly.com/. accessed 12-

March-2016.

Ott, A. and Fischer-H

ubner, S. (2001). The Rule Set Based

Access Control (RSBAC) Framework for Linux. In

Proceedings of ILK.

Singh, J., Bacon, J., and Eyers, D. (2014). Policy enforce-

ment within emerging distributed, event-based sys-

tems. In Proceedings of ACM DEBS, pages 246–255.

ACM.

Spencer, R., Smalley, S., Loscocco, P., Hibler, M., Ander-

sen, D., and Lepreau, J. (1999). The Flask Security

Architecture: System Support for Diverse Security

Policies. In Proceedings of USENIX SS.

Vitek, J., Bryce, C., and Oriol, M. (2003). Coordinating

Processes with Secure Spaces. Science of Computer

Programming, 46(1):163–193.

Wright, C., Cowan, C., Smalley, S., Morris, J., and Kroah-

Hartman, G. (2002). Linux Security Modules: Gen-

eral security support for the Linux kernel. In Proceed-

ings of USENIX SS, pages 17–31.

Xu, Y., Dunn, A. M., Hofmann, O. S., Lee, M. Z., Mehdi,

S. A., and Witchel, E. (2014). Application-Deﬁned

Decentralized Access Control. In Proceedings of

USENIX ATC, pages 395–408.

SECRYPT 2016 - International Conference on Security and Cryptography

182