A Uniform Modeling Pattern for Operating Systems Access Control

Policies with an Application to SELinux

Peter Amthor

Ilmenau University of Technology, Ilmenau, Germany

Keywords:

Security Engineering, Security Policies, Access Control Models, Operating System Security, SELinux.

Abstract:

Modern operating systems increasingly rely on enforcing mandatory access control through the use of secu-

rity policies. Given the critical property of policy correctness in such systems, formal methods and models are

applied for both speciﬁcation and veriﬁcation of these policies. Due to the heterogeneity of their respective

semantics, this is an intricate and error-prone engineering process. However, diverse access control systems

on the one hand and diverse formal criteria of correctness on the other hand have so far impeded a unifying

framework for this task.

This paper presents a step towards this goal. We propose to leverage core-based model engineering, a uniform

approach to security policy formalization, and reﬁne it by adding typical semantic abstractions of contempo-

rary policy-controlled operating systems. This results in a simple, yet highly ﬂexible framework for formaliza-

tion, speciﬁcation and analysis of operating system security policies. We substantiate this claim by applying

our method to the SELinux system and practically demonstrate how to map policy semantics to an instance of

the model.

1 INTRODUCTION

In order to meet tightening security requirements

in most modern application areas, IT systems in-

creasingly rely on formally speciﬁed security policies

(Watson, 2013). These policies deﬁne rules that, re-

liably enforced by a system’s implementation, can be

proven to achieve application-speciﬁc formal proper-

ties concerning security goals such as conﬁdentiality

and integrity of a system and the information it pro-

cesses. A major ﬁeld of application for such secu-

rity policies is the operating systems domain, which

yielded an increasing number policy-controlled op-

erating systems over the past years (Spencer et al.,

1999; Loscocco and Smalley, 2001; Watson and

Vance, 2003; Smalley and Craig, 2013; Russello et al.,

2012; Bugiel et al., 2013; Faden, 2007; Grimes and

Johansson, 2007).

While new methods emerged for design, imple-

mentation and enforcement of OS security policies,

their speciﬁcation and veriﬁcation also received in-

creasing attention. Formal models have been devel-

oped for such policies based on two major objectives:

(1) To precisely specify the semantics of a particular

system, which are determined by its respective appli-

cation domain (such as roles (Sandhu et al., 2000) or

user relationships (Fong and Siahaan, 2011)); (2) to

formalize and subsequently analyze a security prop-

erty, which results from the security requirements of

a particular application domain (such as right prolif-

eration (Harrison et al., 1976; Ferrara et al., 2013)

or information ﬂows (Kafura and Gracanin, 2013)).

Both approaches yield models that are available to

formal methods; however, models resulting from both

approaches are often incompatible: when focusing

on a formally analyzable property such as dynamic

right proliferation, system-independent access control

models based on state machines have proven to be

valuable; when focusing on a formal framework for

policy speciﬁcation and communication on the other

hand, system-speciﬁc models such as for the SELinux

operating system have evolved, which may in turn

sacriﬁce analyzability with respect to a whole family

of security properties.

This problem has been addressed by the design

paradigm of model-based security policy engineer-

ing (Barker, 2009; K

uhnhauser and P

olck, 2011; Ka-

fura and Gracanin, 2013; Amthor et al., 2014; P

olck,

2014). Its goal is to derive a uniform pattern for de-

signing security models, which ﬂexibly ﬁts (1) diverse

security policy semantics as well as (2) diverse formal

analysis goals. Such a uniform pattern would then

Amthor P..

A Uniform Modeling Pattern for Operating Systems Access Control Policies with an Application to SELinux.

DOI: 10.5220/0005551000880099

In Proceedings of the 12th International Conference on Security and Cryptography (SECRYPT-2015), pages 88-99

ISBN: 978-989-758-117-5

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

serve as a fundamental prerequisite for both specify-

ing and verifying security policies.

According to Amthor et al. (2014); P

olck (2014),

this goal can be achieved through a ﬂexible and ex-

tensible common model core based on a determin-

istic state machine (core-based model engineering).

In practice, it requires to adapt domain-speciﬁc ab-

stractions to a deliberately general formal framework.

This yields a twofold result: On the one hand, core-

based model engineering eliminates the need for a

formal approach from scratch, whenever a given se-

curity policy is to be analyzed with one of the two

objectives stated above. On the other hand, given the

versatile and thus domain-independent semantics of

the pattern, the actual engineering effort to create us-

able model instances is still signiﬁcant in practice (as

pointed out by P

olck (2014, pp. 46 et seq.)).

This paper aims at further reducing this engi-

neering effort—and thus the probability of errors—

in the domain of policy-controlled operating systems

by presenting a reﬁnement of the core-based model-

ing pattern. Its idea is based on the general principle

of entity labeling, which can be found in a large fam-

ily of access control (AC) policies for contemporary

operating systems. The resulting modeling pattern

will then be applied to the SELinux operating system,

which exhibits semantic features typical for OS secu-

rity policies. Based on the resulting SELinux access

control model, we will discuss the costs of model de-

sign and model instantiation.

Contributions and Paper Organization. To intro-

duce the context of this paper, we brieﬂy discuss rele-

vant related work (Sec. 2), followed by a summary of

the fundamental concepts of one typical representa-

tive, SELinux (Sec. 3). Sec. 4 focuses on a formaliza-

tion of the discussed concepts: First, the fundamen-

tals of core-based modeling are introduced (Sec. 4.1).

We then present a novel, abstract policy modeling pat-

tern based on entity labeling (Sec. 4.2), which en-

riches the core pattern by adequate access control se-

mantics for the operating systems domain. It hence

eases analysis and veriﬁcation of contemporary oper-

ating system security policies with respect to an actual

system’s protection state (dynamic analysis) using ex-

isting formal methods and tools.

To substantiate this claim, we applied our pattern

to SELinux. We create an entity labeling model of

the SELinux access control system (Sec. 5) and dis-

cuss, how a real-world system’s protection state and

security policy can be transformed into an instance

of this model (Sec. 6). This paves the way for sub-

sequently applying tried and tested analysis methods

for core-based models to SELinux. We conclude with

Section 7.

2 RELATED WORK

In the AC model community, considerable research

has already been done to unify model semantics

and formalisms. Notably, the access control meta-

model by Barker (2009), the Policy Machine (Fer-

raiolo et al., 2011), and core-based security models

uhnhauser and P

olck, 2011; P

olck, 2014) provide

general formal frameworks for a precise speciﬁca-

tion of access control semantics and policies. While

Barker’s unifying meta-model and the Policy Ma-

chine are primarily designed for policy speciﬁcation,

core-based modeling aims at both specifying and an-

alyzing/verifying a policy.

Another family of formal AC models is speciﬁ-

cally tailored to OSs. Among numerous work in this

area, most is tailored to speciﬁc operating systems

such as SELinux (Sarna-Starosta and Stoller, 2004;

Zanin and Mancini, 2004; Xu et al., 2013) or spe-

cial types of OS policies such as MLS (Naldurg and

Raghavendra, 2011). While all of these approaches

emphasize policy analysis with respect to a partic-

ular formal security property, they cannot be easily

adapted to other OS AC semantics or other formal

analysis goals. In our approach, we aim for both:

streamlined adaption to versatile OS AC semantics

that share only the abstract concept of labeling, and

accessibility to a bandwidth of security properties and

their appropriate formal analysis methods.

The basic idea of label-based AC modeling is

far from being new. Dating back to the historical

BLP model (Bell and LaPadula, 1976), which ef-

fectively introduced access permissions based on la-

bels, a whole new class of attribute-based AC models

(ABAC) evolved based on this principle (Zhang et al.,

2005; Kuhn et al., 2010). However, they usually focus

policy speciﬁcation in the domain of service-oriented

architectures (Yuan and Tong, 2005; Shen, 2009; Park

and Chung, 2014) rather than system architectures.

To this end, both the goal of formal policy analysis

and the focus on the OS domain cannot be easily in-

corporated into existing ABAC models.

3 SELinux ACCESS CONTROL

Today’s operating systems increasingly rely on

mandatory access control (MAC) mechanisms gov-

erned by a security policy. In large parts, their au-

thorization semantics are based on assigning policy-

speciﬁc labels to entities, which are divided into

subjects (an activity abstraction such as process or

thread) and objects (OS resources, described by ab-

stractions such as ﬁles, handlers, sockets, etc.). The

idea of label-based OS policies dates back to SELinux

AUniformModelingPatternforOperatingSystemsAccessControlPolicieswithanApplicationtoSELinux

SELinux Security Module

Virtual File System

Driver

Security!

Server

(Policy)

AVC

LSM!

Hook

Application

Hardware

User SpaceKernel Space

(1)

(2)

(4)(3)

(5)

API

Figure 1: Processing an access request in the SELinux se-

curity architecture.

(Loscocco and Smalley, 2001), one of the ﬁrst policy-

controlled OSs, and has been adopted by a wide range

of later operating systems such as SEBSD (Watson

and Vance, 2003), Oracle Solaris (Faden, 2007), Mi-

crosoft Windows (Grimes and Johansson, 2007), and

Google’s Android (Smalley and Craig, 2013).

The goal of this section is to take a closer look

at the security architecture and policy semantics of

SELinux as a typical representative of modern policy-

controlled operating systems.

3.1 Security Architecture

The original goal of SELinux was to enforce MAC in

the Linux operating system. To achieve this, the Flask

security architecture (Spencer et al., 1999) was imple-

mented, which clearly distinguished between policy

enforcement points (PEP) and a singular policy deci-

sion point (PDP). The PDP logically encapsulates the

whole security policy.

Today, SELinux is implemented as a dynamically

loadable kernel module. Its architecture merges into

the Linux kernel through the LSM interface (Linux

Security Modules). It provides ready-made PEP

hooks for all system call implementations, which are

connected to the PDP (the security server) via the

SELinux kernel module. In addition to the process-

ing logic, that translates information about an OS re-

source access into the policy-related data structures

that are used by the security server, this module also

includes a caching mechanism for previously made

decisions (the access vector cache, AVC).

To illustrate how an access request by an appli-

cation process (1) is handled in SELinux, we con-

sider the following example based on Linux kernel

3.19 (cf. Fig. 1): Once an according syscall is pro-

cessed by the kernel, e.g. read() for accessing a ﬁle

(2), the LSM hook (security file permission())

invokes the according interface of the SELinux

Security Module (3). Here, the permissions

needed for authorizing the speciﬁc request (here:

FILE READ) are checked against the AVC (calling

avc has perm()) or, in case of a miss, the secu-

rity server’s security compute av()-interface (4).

The decision is then returned through the LSM

hook and enforced by the read()-implementation in

vfs read() (either invoking the respective ﬁle sys-

tem interface to ultimately access the storage hard-

ware (5), or returning to the caller with an “access

denied” error).

Inside the security server logic, access decisions

are based on the policy rules and SELinux security

contexts associated to entities. The latter is a label

consisting of four attributes, which is usually repre-

sented by a string

user : role : type [: range]

where user is the name of an SELinux user the pro-

cess belongs to, role is the name of an SELinux role

the process assumes, and type is the name of the do-

main (or type) in SELinux type enforcement (TE) in

which the process currently runs. Finally, range is

a collection of conﬁdentiality classes and categories

used by multi-level security (MLS) policy rules based

on the BLP model. Since support for the MLS mech-

anism is neither required by the SELinux policy se-

mantics nor by the security server, this fourth attribute

is optional. We will discuss the semantics of these at-

tributes in a security policy in the next section.

Technically, security contexts of processes are

stored in their management data structures, repre-

sented as a part of the non-persistent /proc ﬁle sys-

tem, while those of objects such as ﬁles or sockets

are stored in extended attributes of the respective ﬁle

system.

3.2 Policy Semantics

As already mentioned, the PDP logic in SELinux is

conﬁgured by a security policy. At runtime, a bi-

nary representation of this policy resides in kernel ad-

dress space; however, as for the rest of this paper,

we will refer to its human-readable speciﬁcation in

SELinux policy language (Smalley, 2005) as “the (se-

curity) policy”.

An SELinux security policy consists of state-

ments, which can be classiﬁed into different types of

rules. Each rule basically supports one of three fun-

damental AC concepts supported by SELinux: type

enforcement (TE), role-based access control (RBAC),

and multi-level security (MLS). The most basic au-

thorization mechanism is implemented through TE,

using TE-allow-rules which basically associate a

SECRYPT2015-InternationalConferenceonSecurityandCryptography

pair of types with a set of permissions: The rule

allow system_t etc_t : file {read execute}

for example will grant any process labeled with the

system t type the right to read and execute any

ﬁle-class object labeled with etc t. We call

system t,etc t,file

the key of above TE-

allow-rule. A second authorization mechanism,

whose support by an SELinux kernel is still optional,

is MLS. Its rules are based on deﬁning a dominance

relation over the attributes conﬁdentiality class and

category, which is then used to limit all read- or write

access to particular objects.

Lastly, the RBAC mechanism is used for

limiting attribute changes of a process. Since

all attributes are changeable except for the user,

this provides a policy administrator with an ad-

ditional, user-centric layer of AC conﬁguration.

RBAC rules deﬁne compatible combinations of all

three major attributes: The role declaration rule

role user_r types { user_t passwd_t } is

necessary to label any process with the user r role

with both types user t and passwd t. Similarly,

any role can be tied to one or more users by the user

declaration rule: user peter roles { admin_r }

is necessary to label any process with user attribute

peter with the admin r role.

As mentioned before, the type- and role-attribute

of a security context may change during runtime

(known as transitions). Accordingly, there are policy

rules to control these changes: For role transitions,

a role-allow-rule allow user_r admin_r is neces-

sary to change the role-attribute user r of a process

to admin r. Note that, despite of the same keyword,

this rule has nothing to do with access authorization

through TE.

For type transitions on the other hand, a special

set of SELinux permissions exists that must be as-

signed to types through the already discussed TE-

allow-rules. Rules with these permissions can be

used for ﬁne-grained control over allowed, forbidden,

or even mandatory type transitions; however, it should

be noted that their semantics are entirely different to

those intended for object access:

• allow init t apache t : process

transition is necessary for a process to

change its type from init t to apache t.

• allow apache t apache exec t : file

entrypoint is necessary for a process to change

its type to apache t during execution of a

program ﬁle of type apache exec t.

• allow init t apache exec t : file

execute no trans is necessary for a pro-

cess with type init t to execute a program ﬁle

of type apache exec t without a type transition.

Since type transitions are intended to exclusively

happen on program execution, the regular permis-

sion execute on apache exec t : file will also

be necessary in each case.

As a last rule type, SELinux policies support con-

straints, that may further restrict (i.e. override) any ac-

cess decision based on the mechanisms discussed so

far. Supported by a limited syntax for nested boolean

expressions, constraints can be used to explicitly for-

bid an access based on the security contexts of both

involved entities and the given logical expression.

4 MODELING PATTERNS

This section introduces the two basic formal ap-

proaches we will use to model the SELinux AC sys-

tem: the core-based modeling pattern by P

olck, and

the novel EL pattern which aims at simplifying a

domain-speciﬁc model engineering for OS AC poli-

cies. Throughout the rest of this paper, we will use

the following conventions for formal notation:

|= is a binary relation between variable assign-

ments and formulas in second-order logic, where I |=

φ iff I is an assignment of unbound variables to values

that satisﬁes φ. In an unambiguous context, we will

write

,...,x

|= φ for any assignment of variables

in φ that satisﬁes φ.

For any mapping f , f [x 7→ y] denotes the mapping

which maps x to y and any other argument x

to f (x

For any mapping f : A → B, f 

denotes a restriction

of f to A

⊂ A that maps any argument x

∈ A

to f (x

whereas f 

(x) is undeﬁned for any x ∈ A \ A

For any set A, 2

denotes the power set of A. B =

{>,⊥} is the set of Boolean values, where > (true) is

interpreted as “allow”, ⊥ (false) as “deny”.

4.1 Core-based Modeling

The goal of the core-based model engineering

paradigm is to establish a uniform formal basis for

speciﬁcation, analysis and implementation of diverse

security models. In this work, we build our modeling

pattern on top of this paradigm to leverage its general-

ity regarding formal analysis methods and its uniform

yet ﬂexible design.

A core-based access control model is described by

an extended state machine

Q,Σ,δ,λ,q

, EXT

(1)

where Q is a (ﬁnite or inﬁnite) set of protection states,

Σ is a (ﬁnite or inﬁnite) set of inputs, δ : Q × Σ → Q is

the state transition function, λ : Q × Σ → B is the out-

put function, q

∈ Q is the initial protection state, and

EXT is an arbitrary tuple of static model extensions.

AUniformModelingPatternforOperatingSystemsAccessControlPolicieswithanApplicationtoSELinux

The state machine serves as a common basis for for-

malizing policy semantics, called model core, which

can be tailored to any domain-speciﬁc security policy

in terms of state members and model extensions.

Based on the abstract deﬁnition above, three

steps are required to describe a particular AC system

through a core-based model (cf. P

olck, 2014, pp. 25

et seq.): (1.) Specializing Q, i.e. explicitly deﬁning

the automaton’s state space members (dynamic model

components). (2.) Specializing EXT, i.e. deﬁning

static model components which are not part of the

automaton’s state. (3.) Specializing δ and λ, i.e.

describing the dynamic behavior of the AC system.

Depending on step (1), the initial protection state q

has to be speciﬁed according to the particular anal-

ysis goal. Depending on both steps (1) and (2), the

input alphabet Σ has to be speciﬁed according to the

interface of the modeled access control system.

In step (3), protection state dynamics are de-

scribed by the state transition function δ through pre-

and post-conditions of every possible state transition.

This is done by comparing each input with two formu-

las in second-order logic, PRE and POST. We then

deﬁne δ by formally specifying the conditions that

each pair of states q and q

has to satisfy w.r.t. an

input σ ∈ Σ for a state transition from q to q

to occur:

δ(q,σ) =



q,σ

|= PRE ∧

,σ

|= POST

q, otherwise.

(2)

Since an access control system is usually determin-

istic, POST fundamentally requires that q

equals q

where not redeﬁned.

Finally, to describe authorization decisions at an

AC system’s interface, the automaton features an out-

put function λ. It enables the analysis of correct pol-

icy behavior and thus supports a formally veriﬁed

speciﬁcation. λ deﬁnes a binary access decision based

on PRE:

λ(q,σ) ⇔

q,σ

|= PRE. (3)

4.2 Entity Labeling

This section describes entity labeling (EL), an ab-

stract semantic modeling pattern for the formalization

of contemporary operating system security policies.

Based on the observations on OS policy semantics

discussed in Section 3, the design goal of an entity

labeling model is to describe access control policies

which

1. use attributes (labels) of system entities for access

decisions

2. have a dynamic protection state

3. are governed by additional constraints, possibly

subject to a dynamically changing context

The domain-speciﬁc semantics of such models is

directly derived from these goals: (1.) To support la-

beling, a basic set of possible label values is needed.

Since our goal is a complete description of an access

control system, a set of entity identiﬁers is needed as

well as an association of these entities with one or

more label values. Then, label-based access rules can

be formalized as well. (2.) To model a dynamic pro-

tection state, these formal concepts can be mapped on

the model core as discussed in Section 4.1. On top

of it, the rules for changing labels of existing entities

(which are also part of a system’s policy) have to be

modeled. (3.) Lastly, model constraints express time-

invariant side conditions for correct behavior of the

AC system. Due to their static nature, such condi-

tions are not part of the automaton’s state; however,

they can of course include variables referencing any

system interface outside the AC system—which is of

increasing importance in mobile systems (e.g. time of

day, NFC device proximity, geographic location, etc.)

(Conti et al., 2012; Shebaro et al., 2014).

In summary, we deﬁne six abstract components of

an EL model, which may be specialized by the se-

mantically appropriate components for describing a

particular policy:

Label Set (LS): A set containing legal label values.

Relabeling Rule (RR): Rule for legal label changes.

Formally, it is usually expressed by a graph.

Entity Set (ES): A set containing identiﬁers of ex-

isting entities in the system.

Label Assignment (LA): An associations between

each entity and its label (or labels). It is usually

expressed by a mapping.

Access Rule (AR): Rule that describes, based on

two or more labels, which operations entities with

these labels are allowed to perform. It is usually

expressed by a mapping or a relation.

Model Constraints (MC): Constraints over the

other components that must be satisﬁed in every

model state. It is usually modeled by a logical

formula.

This design follows the basic idea of model compo-

nent specialization, which has been adopted by the

core-based modeling paradigm from object-oriented

programming.

The above list already implies a suitable formal

notation of these components that we will adhere to;

however, the modeling pattern itself does not dictate

any speciﬁc formalism (other than the extended state

machine required by the model core).

For specializing these abstract model components,

their semantics have to be matched to policy abstrac-

tions of a real system. In order to support model

SECRYPT2015-InternationalConferenceonSecurityandCryptography

dynamics, this also includes decisions about which

specialized components are modiﬁable during policy

runtime—these should be deﬁned within the core-

based model’s state—and which are not. Again, the

EL design does not impose any restrictions on this.

Note that EL spans a subfamily of core-based

models by adding domain-speciﬁc semantic abstrac-

tions to the calculus, which are however orthogonal

to those of the core paradigm. Models in this family

can be further tailored to match contemporary OS se-

curity policies. In the next section, we will show an

example of this based on the SELinux security policy.

5 SELinux SECURITY MODEL

In this section, we will demonstrate the application of

EL on the SELinux operating system. In Section 5.1,

the concepts of the SELinux security policy as de-

scribed in Section 3 will be formalized using the EL

modeling scheme. In Section 5.2, a full core-based

access control model will be deﬁned from these com-

ponents. At last, Section 5.3 proposes a speciﬁcation

for the SELinux-speciﬁc commands and their impact

on protection state transitions and model output.

5.1 EL Components

The abstractions of system resources that are man-

aged by the Linux operating system are completely

covered by the SELinux security policy. Therefore,

we could deﬁne a separate entity set for each of these

abstractions (processes, ﬁles, message queues, sock-

ets, ...). However, the policy semantics are written on

a higher level of granulariy: instead of singular enti-

ties, object classes are used to distinguish between OS

abstractions. Since these classes are assigned to each

system entity on runtime much similar to its respec-

tive security context, we will uniformly model these

information as labels. Consequently, we deﬁne the

following label sets:

• C is the set of SELinux object classes

• U is the set of SELinux users as deﬁned in the

policy

• R is the set of all roles as deﬁned in the policy

• T is the set of all types and domains as deﬁned by

the policy

Moreover, a single entity set E represents all pro-

cesses and other system resources (such as ﬁles, sock-

ets, etc.).

To allow label changes, an SELinux policy

uses special permissions such as transition or

entrypoint, whose semantics drastically differ from

those of other permissions used in TE-allow-rules

(cf. Section 3). To this end, we refrain from modeling

these elements of the policy language as actual access

rules. Instead, type- and role-transitions are modeled

by two relabeling rules as follows:

• 7→

⊆ R

is a binary relation deﬁned as r 7→

iff

a role transition from r to r

is allowed according

to the policy’s role-allow-rules

• 7→

⊆ T

is a ternary relation deﬁned as t

7−→

iff

a type transition from t to t

via an entrypoint type

et is allowed according to the policy’s TE-allow-

rules

User transitions can never be allowed by an SELinux

policy and are therefore not modeled. The above no-

tation serves as a shorthand here; for model checking

purposes, both relations can be interpreted as edges

(weighted in case of 7→

) of directed graphs.

Consequently, the remaining portion of TE-

allow-rules in a policy is modeled by the following

access rule. The mapping allow : T × T × C → 2

represents the combined semantics of all TE-allow-

rules:

allow(t

,c) ={p | an allow-rule for p with key

exists in the policy}

where P is the set of SELinux permissions.

As already mentioned, SELinux stores label as-

signments as part of its protection state rather than in

the policy. Nevertheless, we need to model the fol-

lowing label assignments for a meaningful analysis

of the model’s dynamic protection state:

• cl : E → C is the class assignment, which labels

each entity with its SELinux object class.

• con : E → SC is the context assignment, which la-

bels each entity with its SELinux security context.

Here, the set of security contexts SC = U ×R × T

represents all possible security contexts (labels)

for entities under the given policy.

Concluding, two further restrictions on type- and

role transitions have to be taken into account: those

imposed by user and role declarations. For both, we

use the following model constraints:

• UR ⊆ U × R associates users with roles they are

allowed to assume according to the security pol-

icy’s user declaration statements

• RT ⊆ R × T associates roles with types they are

allowed to assume according to the security pol-

icy’s role declaration statements

• τ

::= ∀e ∈ E : con(e) =

u,r,t

⇒

u,r

∈ UR

ensures that no role is assumed a user is not au-

thorized for

• τ

::= ∀e ∈ E : con(e) =

u,r,t

⇒

r,t

∈ RT

ensures that no type is assumed a role is not au-

thorized for

AUniformModelingPatternforOperatingSystemsAccessControlPolicieswithanApplicationtoSELinux

Table 1: Classiﬁcation of SELX model components in EL

and core-based modeling patterns.

EL Component Q Members EXT Members

LS — C,U,R,T

RR — 7→

,7→

ES E —

LA cl,con —

AR — allow,P

MC — τ

,τ

,UR,RT

5.2 Core-based Model

The formal EL components deﬁned above will be put

into context of a core-based model now. Therefore,

it has to be decided which component is part of the

automaton’s state (thus dynamic) and which is part of

the extension vector (thus static). In case of SELinux,

these components directly reﬂect the semantics of a

policy that conﬁgures the security server, which again

is static during runtime—except for E, cl and con.

This results in the classiﬁcation shown in Table 1.

According to the basic deﬁnition of the model core

(1), we deﬁne an EL model for SELinux as a tuple

SELX =

Q,Σ,δ,λ,q

, EXT

where

Q = 2

× CL × CON

Σ = Σ

× Σ

EXT =

C,U,R,T,7→

,7→

,allow,P, τ

,τ

,UR,RT

Each state q ∈ Q of the model is a triple



,cl

,con



with the semantics deﬁned above,

where we use the sets E

⊆ E of all entities in state

q, CL = {cl

|cl

: E

→ C} of all state-speciﬁc class

assignments, and CON = {con

|con

: E

→ SC} of

all state-speciﬁc context assignments. The input set

Σ is deﬁned by a set of commands Σ

(that may be

SELinux system calls, but also operations on applica-

tion level for different implementations) and a set of

arbitrary parameter sequences Σ

= (E ∪C ∪ P ∪U ∪

R ∪ T )

∗

. δ and λ are deﬁned as in deﬁnitions (2) and

(3) on page 5. The extensions in EXT are deﬁned as

given in Sec. 5.1.

Both δ and λ are controlled by the conditions PRE

and POST, which are partially deﬁned using the fol-

lowing scheme. For each element of a model-speciﬁc

set of commands cmd ∈ Σ

along with its parameters

vector x

cmd

∈ Σ

, we write:

For the sake of brevity, we refrained from including

both MLS and constraints in this model. Note that, how-

ever, amending the formal components by LSs and LAs for

“classiﬁcation” and “category”, an AR for the dominance

relation and another set of MC expressions is a straight-

forward task.

I cmd(x

cmd

) ::=

PRE: φ

∧ ··· ∧ φ

;

POST: ψ

∧ ψ

CON

∧ ψ

where φ

and ψ

are expressions that q, q

and x

cmd

should satisfy. While the above notation is used to

deﬁne PRE(cmd) and POST(cmd) of each command,

these conditions constitute the global terms:

PRE =

cmd∈Σ



σ =

cmd,x

cmd

∧ PRE(cmd)



POST =

cmd∈Σ



σ =

cmd,x

cmd

∧ POST(cmd)



While any number of arbitrary pre-condition

clauses can be used in this scheme, post-conditions

require a stricter pattern due to the fact that each

command deﬁnition should yield exactly one possible

follow-up state: Since post-conditions describe the

modiﬁcations that q

should undergo with respect to

q, the ﬁrst three boolean clauses ensure an unambigu-

ous deﬁnition of the entity set (ψ

), class assignment

(ψ

), and context assignment (ψ

CON

) of q

. This re-

quirement has to be considered for each speciﬁc EL

model based on its particular state members. The last

clause ψ

is mandatory, since it ensures that model

constraints are satisﬁed in each follow-up state. In

case of SELX, it is deﬁned as

::= q

|= τ

∧ q

|= τ

while q

|= τ

∧ q

|= τ

must also hold for every

correct SELX model instance.

For brevity, we will omit any of these clauses

when writing command deﬁnitions iff the respective

state component in q and q

is equal. ψ

will be

generally considered implicit due to its mandatory na-

ture.

5.3 Specifying SELX Commands

As an input to the state machine that triggers state

transitions and output (access decisions), commands

are the interface between a formalized security policy

and a formalized analysis goal. As in most complex

security architectures, security-relevant commands in

an SELinux system may be modeled on at least two

different levels of abstraction (see Fig. 2): (I) at PEP

level, i.e. based on the access handling logic in the

SELinux security module; (II) at API level, thus cov-

ering the rich and complex semantics of all API calls.

In practice, there is another choice to make here: ei-

ther modeling library wrapper functions only, or including

the syscall interface of the Linux kernel. Again, the deci-

sion depends on whether our respective analysis scenario

includes applications that directly use syscalls. We will not

further go into detail on when to prefer which degree of de-

tail, and assume in the following that both are modeled.

SECRYPT2015-InternationalConferenceonSecurityandCryptography

SELinux Security Module

Security!

Server

(Policy)

AVC

Virtual File System

Driver

LSM!

Hook

Application

libc libselinux ...

System Call Interface

API

Hardware

User SpaceKernel Space

(I)

(II)

Figure 2: Semantical levels for modeling commands.

Both semantical levels may be used depending

on a particular analysis scenario: If a security engi-

neer has the goal to verify a given policy based on

the behavior of the security server, she will opt for

Level I (in practice, this may be relevant e.g. if an

attacker model includes control ﬂow or code manipu-

lation in a user process’ address space). On the other

hand, if the focus is on OS behavior from a user space

perspective—considering kernel implementation as a

black box—Level II commands have to be speciﬁed,

accepting the more comprehensive and detailed de-

gree of security-relevant interaction that is capsuled in

an SELinux API call. In practice, given the huge ﬂex-

ibility of the Linux kernel with respect to differing li-

brary wrappers, kernel features and architectures, API

implementations may vary in any case—thus yielding

different command speciﬁcations in the model.

Moreover, complexity of the state transition func-

tion that results from command speciﬁcation is an-

other important point in question. As previous work

on model analysis has shown (Harrison et al., 1976;

Sandhu, 1992; Stoller et al., 2011; Amthor et al.,

2013), most approaches stand or fall with a certain de-

gree of complexity. Thus, a clean separation of Level

I and Level II commands serves two goals:

I. Keep command speciﬁcations as small and uni-

form as possible, even across different SELinux

implementations, to support dynamic model

analysis.

II. Enable ﬂexible speciﬁcation of tailored,

implementation-speciﬁc model dynamics that

expose a high-level interface for security

analyses on application level.

Since Level II commands have to partially in-

clude the semantics of Level I commands, a two-

step approach for modeling dynamics in SELX seems

promising: We ﬁrst specify a small number of com-

mands on Level I (Sec. 5.3.1), that are general enough

to be used for every SELinux implementation. We

then deﬁne a pattern for specifying commands on

Level II (Sec. 5.3.2), that leverages the previous spec-

iﬁcations and may thus be disassembled into Level I

commands.

5.3.1 Basic Commands

Level I commands, which we call basic commands,

are access, create, remove, and relabel. They are de-

ﬁned as follows.

access speciﬁes the semantics of any access

decision. It does not model any state transitions and

thus impacts only the automaton’s output (λ). Any

access by a process e to an entity e

that requires

permission p is deﬁned as

I access(e,e

, p) ::=

PRE: {e,e

} ⊆ E

∧ cl

(e) = process

∧ cl

) = c

∧ con

(e) =

u,r,t

∧ con

) =

∧ p ∈ allow(t,t

) ;

POST: >

create speciﬁes how a new entity is created in the

protection system. In SELX, this entity may represent

a resource such as a ﬁle, directory, or a socket, but

also a process. Any creation of an entity e

of class c

with parent entity

e is deﬁned as

I create(e,e

) ::=

PRE: e ∈ E

∧ e

∈ E \E

∧ c

∈ C

∧ con

(e) =

u,r,t

;

POST: E

= E

∪ {e

}

∧ cl

= cl

7→ c

]

∧ con

= con

7→

u,r,t

]

Corresponding to create, remove speciﬁes remov-

ing an entity e from the system:

I remove(e) ::=

PRE: e ∈ E

;

POST: E

= E

\ {e}

∧ cl

= cl



∧ con

= con



SELinux uses the term “parent entity” to generalize the

concept of label inheritance: whenever a process is created,

e is its parent process; whenever a ﬁle or directory is cre-

ated, it is the respective parent directory.

AUniformModelingPatternforOperatingSystemsAccessControlPolicieswithanApplicationtoSELinux

In an EL model, assigning new permissions to

entities is done through labels. For SELX, a last

basic command is needed that describes relabeling

processes with a new security context. In SELinux,

such process transitions occur on the execution of

an “entrypoint” program. Changing the security

context of a process e to a role r

and a type t

via an

entrypoint program ﬁle f is deﬁned as

I relabel(e, f ,r

) ::=

PRE: e ∈ E

∧ cl

(e) = process

∧ con

(e) =

u,r,t

∧ con

( f ) =

uf ,rf ,tf

∧ r 7→

∧ t

7−→

;

POST: con

= con

[e 7→

u,r

]

Note that, from an abstract view, this collection of

basic commands expresses operations fundamental to

every EL model—even though their particular PRE

and POST terms have been tailored to SELinux poli-

cies. This is another example for our basic assump-

tion towards the generality of the EL model family,

and how it can be leveraged to enhance the model-

based engineering idea in the OS domain.

5.3.2 Composed Commands

Based on the speciﬁcations of basic commands, we

can now give a design pattern for such commands that

model a speciﬁc system’s API. For this purpose, we

compose such Level II commands by using the com-

position operator ◦ : Σ × Σ ∪ {ε} → Σ, which is de-

ﬁned as follows:

◦ ε ::=

◦

::=

where x

∈ Σ

is a concatenated parameter

sequence and c

∈ Σ

is a composed command

deﬁned as

I c

) ::=

PRE: PRE(c

) ∧ PRE(c

) ;

POST: POST(c

) ∧ POST(c

)

We can then model any interface to the SELinux

security policy by the resulting composed commands.

As an example, an execve() call may be composed as

follows:

 execve(caller, exec

ﬁle, exec dir, post r, post t) ::=

access(caller, exec dir, search)

◦ access(caller, exec ﬁle, execute)

◦ access(caller, exec ﬁle, read)

◦ access(caller, exec ﬁle, open)

◦ access(caller, exec ﬁle, getattr)

◦ relabel(caller, exec ﬁle, post r, post t)

where caller ∈ E

is the calling process, exec ﬁle ∈ E

is the program ﬁle to execute, exec dir ∈ E

is the

directory of the program ﬁle, post r is the role that

should be assumed by caller after execution, and

post t is the type that should be assumed by caller

after execution.

Note that using composed commands, access con-

trol semantics of different granularity can be mod-

eled: since basic commands cover all relevant behav-

ior of the security policy, they can be composed on

API level (outlined above), but as well on bare syscall

level or even on level of a particular middleware in-

terface.

6 MODEL INSTANTIATION

The goal of this section is to demonstrate how to ex-

tract model components from a real-world SELinux

system. Note that this is only one of two possible

model analysis use cases in practice: the other one

focuses on designing an SELinux-based AC system

from scratch, including API design and the policy it-

self. The practical process however can be considered

symmetrical to the one outlined in the following.

As discussed in Sec. 4.1, there are generally three

specialized deﬁnitions required to tailor a core-based

model to a particular AC system: the automaton’s

state space (Q), model extensions (EXT), and model

dynamics (δ and λ). In the following, we present our

methods to perform each of these three steps in prac-

tice. We used a Linux 3.19 kernel in a Debian distri-

bution with SELinux enabled; for most of the follow-

ing steps, tools of our model engineering workbench

WorSE (Amthor et al., 2014) have been used.

6.1 State Space

A protection state in SELX consists of an entity set

and label assignments. Entities in SELinux are pro-

cesses, whose labels are stored in the attr names-

pace of the /proc ﬁle system, and ﬁles representing

OS objects, whose labels are stored in extended ﬁle

system attributes.

Consequently, a protection state can be extracted

from an SELinux system by parsing the whole ﬁle

system. In practice, we build on our previous work

described in Amthor et al. (2011) and Amthor et al.

(2014, p. 49): a ﬁle system crawler, originally in-

tended for extracting ACLs from inodes, was slightly

modiﬁed to recursively scan through a ﬁle system and

extract each inode number i along with its associ-

ated ﬁle type ft and the associated SELinux security

context sec using stat. These information are then

compiled to form the initial state of the model, where

SECRYPT2015-InternationalConferenceonSecurityandCryptography

i ∈ E

,cl

(i) = ft,con

(i) = sec.

For processes,

the directories /proc/pid/attr are scanned with a

similar result.

Further information about more technical ques-

tions such as snapshot consistency can be found in

the aforementioned papers.

6.2 Model Extensions

The static model extensions in SELX consist of autho-

rization and relabeling rules, which are equivalent to

particular rule types in the SELinux security policy,

and label sets these rules are based on. Model con-

straints regarding user-/role-/type-compatibility cor-

respond to another type of policy rules.

To extract model extensions, we have modiﬁed the

policy compiler sepol2hru from Amthor et al. (2011).

It parses policy source ﬁles in plain syntax, i.e. af-

ter expanding auxiliary m4-macros, and produces an

XML-based speciﬁcation for the components of EXT.

For evaluation purposes, we have applied it on a ba-

sic, non-MLS conﬁguration of the reference policy by

Tresys Technology (PeBenito et al., 2006).

The modiﬁed compiler is designed to isomorphi-

cally map statements in the SELinux policy language

to deﬁnitions of the EXT components as follows:

Elements of C,P,U,R and T are explicitly de-

clared through the statements class, common, user,

role, and type.

allow is deﬁned by assembling all TE-allow-

statements as described in Sec. 5.1. We do not take

into account the neverallow rule of the policy lan-

guage, since it acts similar to an assertion tested by

the policy compiler, but not reﬂected in any way in the

resulting binary policy that steers the security server.

UR and RT are deﬁned by assembling all user-

and role-statements as described in Sec. 5.1.

7→

is deﬁned by assembling all role-allow-

statements. For each parsed rule i > 0 of the form

allow { r

...r

} { r

...r

}, 7→

is extended iter-

atively as follows:

• 7→

i+1

= 7→

∪{r

...r

} × {r

...r

}

The result is 7→

=7→

, where n denotes the total num-

ber of parsed role transition rules.

7→

is deﬁned by assembling all TE-allow-

statements for one of the three permissions

transition, entrypoint, and execute no trans

(we investigated their respective semantics in

Sec. 3.2). Depending on which permission p is

assigned to a key

by a parsed rule i > 0,

Technically, there is another, isomorphic mapping of

ﬁle types to object classes that yields cl

(i) based on ft.

7→

is extended iteratively using the transition graph

union operator t as follows:

• 7→

• p = transition ∧ c = process

⇒ 7→

i+1

= 7→

,ε,t

• p = entrypoint ∧ c = file

⇒ 7→

i+1

= 7→

ε,t

• p = execute

no trans ∧ c = file

⇒ 7→

i+1

= 7→

where t : 2

× T

→ 2

is deﬁned as in Def. 4 on

page 11. The result is 7→

=7→

, where m denotes the

total number of parsed type transition rules.

6.3 Model Dynamics

The dynamic behavior of the SELinux AC system is

based on the implementation of both the SELinux

security module and library wrappers of API calls.

While the combination of both leads to the deﬁnition

of composed commands, basic commands solely de-

pend on the PDP logic and thus stick to their funda-

mental semantics, independent from an actual AC in-

terface. As already discussed in Sec. 5.3, we consider

this one of their essential merits.

In contrast to the other model components, ex-

tracting the deﬁnitions of composed commands is a

task that cannot be automated. It requires insight into

the implementation behind the desired interface, in

our case both of the kernel and any wrapper func-

tions. We have restricted to a subset of common

syscalls in this study, such as fork(), execve(), read()

etc. Once LSM hooks involved in a syscall have been

identiﬁed, such as security file permission()

in the example of read() in Sec. 3.1, specifying a

composed command usually boils down to tracking

subsequent calls of the avc has perm()-function in

the SELinux security module. These give informa-

tion about which parameters for the access basic

command are needed. Moreover, protection-state-

changing system calls such as fork() or execve() in-

clude more logic such as for relabeling or entity cre-

ation, and thus require the corresponding basic com-

mands. An example of this was shown in Sec. 5.3.2.

Note that, when specifying composed commands,

we are not interested in mere information retrieval

concerning entity names and contexts, default type

transitions and the like (which is why we did not con-

sider the latter in the execve composed command). In-

stead, our goal is to model AC-related logic as pre-

cisely as possible, while any additional management

logic for protection state data is deliberately excluded.

This supports a clean separation of security model and

AUniformModelingPatternforOperatingSystemsAccessControlPolicieswithanApplicationtoSELinux

A t







A ∪ {

ε,a

∈ A} ∪ {

,ε,a

}, a

= ε

A ∪ {

,ε,a

∈ A} ∪ {

ε,a

}, a

= ε

A ∪ {

} ε /∈ {a

}

(4)

analysis scenario, that may provide any of this infor-

mation through the model’s formal interface (i.e. via

command parameters).

6.4 Result

Using the techniques described in this section, our

method yields a machine-readable speciﬁcation of

a formal SELX model in ELM, an XML-based EL

model format, which can be parsed by model anal-

ysis and veriﬁcation tools such as WorSE (cf. Amthor

et al., 2014, Sec. 4).

To get a better understanding of model complex-

ity and scalability in real-world scenarios, we are

currently conducting studies on different SELinux-

based setups whose evaluation with respect to dif-

ferent analysis goals will be subject to future work.

As a quantitative example, a real policy of one of our

group’s web servers included 2,847 types, 22 roles, 18

users, 4,330 relabeling rules, and 130,912 authoriza-

tion rules. The corresponding protection state consists

of approx. 390,000 entities, each with their associated

security context labels.

7 CONCLUSIONS

In this paper, we addressed the problem of creating

a uniform yet ﬂexible access control model for oper-

ating system security policies. We aimed at comple-

menting the core-based model engineering approach

with an abstract, label-based modeling pattern that

helps in tailoring the automaton’s components to an

OS AC system.

After discussing essential properties of a typical

policy for the SELinux OS, we have presented the de-

sign of a formal policy model for this OS based on

core-based entity labeling pattern. We have substanti-

ated its feasibility by demonstrating a model instanti-

ation method for the analysis of a real-world system.

This provides the basis for a tool-based formal analy-

sis of SELinux-style security policies.

Regarding the costs of model engineering in this

case study, we made two major observations: First,

tailoring the core-based pattern to the SELinux AC

system was streamlined considerably by using the

ready-made abstract categories of the EL pattern. We

thus argue that, based on these categories, other OS

security policies can be formalized in a very similar

manner. Second, instantiating the model for a real-

world system essentially required manual effort for

formalizing commands. Here, a two-stage pattern

consisting of basic commands and composed com-

mands helps to reduce modeling complexity; again,

we argue for this approach to be adaptable to other

policy-controlled OSs.

Major ongoing work includes (1) an adaption of

formal analysis methods for standard security proper-

ties based on state reachability, (2) generalization and

evaluation of our framework based on a large family

of OS policies, and (3) a pattern-based formal proof

of model-to-policy isomorphism.

REFERENCES

Amthor, P., K

uhnhauser, W. E., and P

olck, A. (2011).

Model-based Safety Analysis of SELinux Security Poli-

cies. In Samarati, P., Foresti, S., Hu, J., and Livraga,

G., editors, In Proc. 5th Int. Conference on Network and

System Security, pages 208–215. IEEE.

Amthor, P., K

uhnhauser, W. E., and P

olck, A. (2013).

Heuristic Safety Analysis of Access Control Models. In

Proc. 18th ACM symposium on Access control models

and technologies, SACMAT ’13, pages 137–148, New

York, NY, USA. ACM.

Amthor, P., K

uhnhauser, W. E., and P

olck, A. (2014).

WorSE: A Workbench for Model-based Security Engi-

neering. Computers & Security, 42(0):40–55.

Barker, S. (2009). The Next 700 Access Control Models or

a Unifying Meta-Model? In Proc. 14th ACM Symposium

on Access Control Models and Technologies, SACMAT

’09, pages 187–196, New York, NY, USA. ACM.

Bell, D. and LaPadula, L. (1976). Secure Computer System:

Uniﬁed Exposition and Multics Interpretation. Technical

Report AD-A023 588, MITRE.

Bugiel, S., Heuser, S., and Sadeghi, A.-R. (2013). Flexi-

ble and Fine-Grained Mandatory Access Control on An-

droid for Diverse Security and Privacy Policies. In 22nd

USENIX Security Symposium (USENIX Security ’13).

USENIX.

Conti, M., Crispo, B., Fernandes, E., and Zhauniarovich,

Y. (2012). Cr

epe: A system for enforcing ﬁne-grained

context-related policies on android. Information Foren-

sics and Security, IEEE Transactions on, 7(5):1426–

1438.

Faden, G. (2007). Multilevel Filesystems in Solaris Trusted

Extensions. In Proc. 12th ACM Symposium on Access

Control Models and Technologies, SACMAT ’07, pages

121–126, New York, NY, USA. ACM.

Ferraiolo, D., Atluri, V., and Gavrila, S. (2011). The Pol-

icy Machine: A Novel Architecture and Framework for

SECRYPT2015-InternationalConferenceonSecurityandCryptography

Access Control Policy Speciﬁcation and Enforcement.

Journal of Systems Architecture: the EUROMICRO Jour-

nal, 57(4):412–424.

Ferrara, A. L., Madhusudan, P., and Parlato, G. (2013).

Policy Analysis for Self-administrated Role-based Ac-

cess Control. In Proc. 19th International Conference on

Tools and Algorithms for the Construction and Analysis

of Systems, TACAS’13, pages 432–447, Berlin, Heidel-

berg. Springer-Verlag.

Fong, P. W. and Siahaan, I. (2011). Relationship-based Ac-

cess Control Policies and Their Policy Languages. In

Proc. 16th ACM Symposium on Access Control Mod-

els and Technologies, SACMAT ’11, pages 51–60, New

York, NY, USA. ACM.

Grimes, R. A. and Johansson, J. M. (2007). Windows Vista

Security: Securing Vista Against Malicious Attacks. John

Wiley & Sons, Inc., New York, NY, USA.

Harrison, M. A., Ruzzo, W. L., and Ullman, J. D. (1976).

Protection in Operating Systems. Communications of the

ACM, 19(8):461–471.

Kafura, D. and Gracanin, D. (2013). An Information Flow

Control Meta-model. In Proc. 18th ACM Symposium on

Access Control Models and Technologies, SACMAT ’13,

pages 101–112, New York, NY, USA. ACM.

Kuhn, D., Coyne, E., and Weil, T. (2010). Adding At-

tributes to Role-Based Access Control. IEEE Computer,

43(6):79–81.

uhnhauser, W. E. and P

olck, A. (2011). Towards Access

Control Model Engineering. In Proc. 7th Int. Conf. on

Information Systems Security, ICISS’11, pages 379–382,

Berlin, Heidelberg. Springer-Verlag.

Loscocco, P. A. and Smalley, S. D. (2001). Integrating Flex-

ible Support for Security Policies into the Linux Operat-

ing System. In Cole, C., editor, 2001 USENIX Annual

Technical Conference, pages 29–42.

Naldurg, P. and Raghavendra, K. (2011). SEAL: A Logic

Programming Framework for Specifying and Verifying

Access Control Models. In Proc. 16th ACM Symposium

on Access Control Models and Technologies, SACMAT

’11, pages 83–92, New York, NY, USA. ACM.

Park, S. M. and Chung, S. M. (2014). Privacy-preserving

Attribute-based Access Control for Grid Computing. Int.

J. Grid Util. Comput., 5(4):286–296.

PeBenito, C. J., Mayer, F., and MacMillan, K. (2006). Ref-

erence Policy for Security Enhanced Linux. In Proc. 3rd

Annual SELinux Symposium.

olck, A. (2014). Small TCBs of Policy-controlled Operat-

ing Systems. Universit

atsverlag Ilmenau.

Russello, G., Conti, M., Crispo, B., and Fernandes, E.

(2012). MOSES: Supporting Operation Modes on Smart-

phones. In Proc. 17th ACM symposium on Access Con-

trol Models and Technologies, SACMAT ’12, pages 3–

12, New York, NY, USA. ACM.

Sandhu, R., Ferraiolo, D., and Kuhn, R. (2000). The NIST

Model for Role-Based Access Control: Towards a Uni-

ﬁed Standard. In Proc. 5th ACM Workshop on Role-

Based Access Control, pages 47–63, New York, NY,

USA. ACM. ISBN 1-58113-259-X.

Sandhu, R. S. (1992). The Typed Access Matrix Model. In

Proc. 1992 IEEE Symposium on Security and Privacy,

SP ’92, pages 122–136, Washington, DC, USA. IEEE

Computer Society.

Sarna-Starosta, B. and Stoller, S. D. (2004). Policy Analysis

for Security-Enhanced Linux. In Proc. 2004 Workshop

on Issues in the Theory of Security (WITS).

Shebaro, B., Oluwatimi, O., and Bertino, E. (2014).

Context-based Access Control Systems for Mobile De-

vices. IEEE Transactions on Dependable and Secure

Computing, PP(99):1–1.

Shen, H. (2009). A Semantic-Aware Attribute-Based Ac-

cess Control Model for Web Services. In Proc. 9th In-

ternational Conference on Algorithms and Architectures

for Parallel Processing, ICA3PP ’09, pages 693–703,

Berlin, Heidelberg. Springer-Verlag.

Smalley, S. and Craig, R. (2013). Security Enhanced (SE)

Android: Bringing Flexible MAC to Android. In 20th

Annual Network & Distributed System Security Sympo-

sium (NDSS).

Smalley, S. D. (2005). Conﬁguring the SELinux Policy.

Technical Report 02-007, NAI Labs.

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

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

chitecture: System Support for Diverse Security Policies.

In Proc. 8th USENIX Security Symposium.

Stoller, S. D., Yang, P., Gofman, M., and Ramakrishnan,

C. R. (2011). Symbolic Reachability Analysis for Pa-

rameterized Administrative Role Based Access Control.

Computers & Security, 30(2-3):148–164.

Watson, R. and Vance, C. (2003). Security-Enhanced

BSD. Technical report, Network Associates Laborato-

ries, Rockville, MD, USA.

Watson, R. N. M. (2013). A Decade of OS Access-control

Extensibility. ACM Queue, 11(1):20:20–20:41.

Xu, W., Shehab, M., and Ahn, G.-J. (2013). Visualization-

based policy analysis for SELinux: framework and user

study. International Journal of Information Security,

12(3):155–171.

Yuan, E. and Tong, J. (2005). Attributed Based Access Con-

trol (ABAC) for Web Services. In ICWS ’05: Proc. IEEE

International Conference on Web Services, pages 561–

569, Washington, DC, USA. IEEE Press.

Zanin, G. and Mancini, L. V. (2004). Towards a Formal

Model for Security Policies Speciﬁcation and Validation

in the SELinux System. In Proc. of the 9th ACM Sympo-

sium on Access Control Models and Technologies, pages

136–145. ACM.

Zhang, X., Li, Y., and Nalla, D. (2005). An Attribute-based

Access Matrix Model. In Proc. 2005 ACM Symposium

on Applied Computing, SAC ’05, pages 359–363, New

York, NY, USA. ACM.

AUniformModelingPatternforOperatingSystemsAccessControlPolicieswithanApplicationtoSELinux