Evaluating the Comprehensive Complexity of Authorization-based
Access Control Policies using Quantitative Metrics
Malek Belhaouane, Joaquin Garcia-Alfaro and Herv
´
e Debar
Institut Mines-Telecom, T
´
el
´
ecom SudParis, CNRS Samovar UMR 5157, Evry, France
Keywords:
ICT Security, Authorization, Access Control, Quantitative Security, Security Assurance, Security Metrics.
Abstract:
Access control models allow flexible authoring and management of security policies, using high-level state-
ments. They enable the expression of structured and expressive policies. However, they have an impact on
the policy characteristics. The complexity of such policies is one of the affected characteristics. We propose
a series of quantitative metrics to assess comprehensive complexity of policies. By comprehensive, we mean
the difficulty of understanding a policy by administrators. We formalize the concepts of authorization-based
access control models, to propose general metrics regardless of the model. We also show the application of
the proposed metrics through a content management system (CMS) policy example. We outline a proof-of-
concept to evaluate the feasibility of our proposal, based on SELinux policies for a general-purpose CMS.
1 INTRODUCTION
Access control is a security fundamental concern. It
covers a wide area of applications. An access control
rule can be defined as a decision (e.g., allow or deny)
for an access request (a subject who wants to perform
an action on an object). As a consequence, an ac-
cess control policy can simply be modeled as a set of
quadruplets <decision, subject, action, object>. This
is a really simple modeling of access control policies,
called identity-based access control (IBAC) model-
ing. Using IBAC models (Lampson, 1969; Lampson,
1974; Harrison et al., 1976), the number of rules in
a policy can dramatically increase. With many rules,
the task of generating and managing an access control
policy may become difficult and error-prone (Garcia-
Alfaro et al., 2006).
To simplify the management of access control
rules, modern access control models allow a flex-
ible and easy expression of access control poli-
cies by the use of high-level statements (Sama-
rati and De Capitani di Vimercati, 2000). Access
control models such as Role-Based Access Control
(RBAC) (Sandhu et al., 1996), Attribute-Based Ac-
cess Control (ABAC) (Yuan and Tong, 2005) or
Organization-Based Access Control (OrBAC) (Abou-
El-Kalam et al., 2003) attempt to reduce the system
administrators effort by introducing a level of abstrac-
tion that enables the aggregation of statements. In
addition, these models allow the definition of con-
straints to structure the policy management process.
Even when using these models, the tasks of design-
ing and managing access control policies are still
not trivial. Abstraction and constraints have an im-
pact on policy characteristics such as security and
usability (Beckerle and Martucci, 2013), policy cov-
erage (Martin et al., 2006), and both conflict (Cup-
pens et al., 2007) and exception management (Garcia-
Alfaro et al., 2007).
In this paper, we focus on the comprehensive com-
plexity of a policy as its core characteristic. We mean
by comprehensive complexity, the the reasoning ef-
fort needed to understand a policy. Complex access
control policies are difficult to maintain and tend to
have inconsistencies and errors, such as redundant or
conflicting rules (Garcia-Alfaro et al., 2008; Garcia-
Alfaro et al., 2013). There is a need for tools to
measure and evaluate access control characteristics as
well as to optimize the policy management process.
Our goal is to provide means to evaluate the com-
prehensive complexity of authorization-based access
control policies. By comprehensive, we mean the dif-
ficulty of understanding a policy by administrators.
We formalize the basics of authorization-based access
control models and define quantitative metrics. The
metrics are applied to a content management system
(CMS) policy example. We also present a proof-of-
concept implementation, based on SELinux policies,
for a general-purpose CMS to validate the feasibility
of our approach.
53
Belhaouane M., Garcia-Alfaro J. and Debar H..
Evaluating the Comprehensive Complexity of Authorization-based Access Control Policies using Quantitative Metrics.
DOI: 10.5220/0005544100530064
In Proceedings of the 12th International Conference on Security and Cryptography (SECRYPT-2015), pages 53-64
ISBN: 978-989-758-117-5
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
Section 2 presents our motivation and illustrates
some of the basic concepts with a practical example.
Section 3 formalizes the concepts of authorization-
based access control models. Section 4 defines the
comprehensive complexity of policies and present our
metrics to measure this characteristic of access con-
trol policies. Section 5 describes a practical applica-
tion of our proposal. Section 6 provides a comparison
with related work. Section 7 closes the paper.
2 MOTIVATION
The tasks of authoring and managing access control
policies are not necessarily handled by specialists in
computer security but frequently delegated, e.g., to
human resources, or performed in several places by
different people. It is sure that the abstraction intro-
duced in access control models (Sandhu et al., 1996;
Yuan and Tong, 2005; Abou-El-Kalam et al., 2003)
helps in reducing the effort of administrators, but it
has an impact on the policy characteristics such as the
complexity of understanding the policy by adminis-
trators. In addition, constraints introduced in these
models help administrators to design structured poli-
cies and to respect functional restrictions. However,
such constraints are challenging from two perspec-
tives. First, they require additional checks when ad-
ministrating the policy. Second, constraints make it
more difficult for human to manage and correctly un-
derstanding a policy. Managing complex policies is
an error-prone task for administrators.
In order to assess strategies to reduce the complex-
ity of policies, we propose metrics to measure their
comprehensive complexity. In the sequel, we describe
a concrete example about the complexity of access
control policies.
2.1 Complexity Example
Our example describes the access control policy of
a content management system (CMS) providing an
electronic newspaper (e.g., based on solutions such
as Wordpress (Wordpress Web Site, 2015) or Drupal
(The Drupal project, 2015)). We present a simplified
version of roles and actions. For simplicity reasons,
we omit as well the administration tasks of the as-
sumed CMS.
The scenario defines the type of access a subject
has on a post. Subjects are classified into three cate-
gories: contributors, publishers and subscribers. We
distinguish three types of subscribers: general news
subscribers, economic news subscribers and sports
news subscribers. The general news subscription is
a default subscription for all subscribers. The two
other subscriptions are optional. In addition, a sub-
ject can not be a contributor and a publisher at the
same time. The posts are also classified into three
types: general news posts, sports news posts and eco-
nomic news posts. Each post can only be assigned to
one category. Contributors have the right to write any
type of posts. Publishers have the permission to mod-
ify (write) and publish posts. Subscribers have the
permission to only read posts allowed by their sub-
scriptions. Finally, we model the scenario as follows:
• A table of subjects and their attributes (cf. Ta-
ble 1a).
• A table of objects and their attributes (cf. Ta-
ble 1b).
• A table describing the policy (cf. Table 2).
In our scenario, we assign to each subject at-
tributes (A1, A2, A3, A4, A5) that reflect its role in
the CMS (cf. Table 1a). We also assign to each post
attributes (A6, A7, A8) that indicate its type (see Ta-
ble 1b).
In our scenario, attributes are not the conven-
tional attributes described in the ABAC model. In the
ABAC model, an attribute can take different possi-
ble values and the attribute value is either a simple
value or a set of values. Attributes in our scenario are
equivalent to domains and types in the Domain and
Type Enforcement model (Badger et al., 1996). For
instance, subjects in a DTE environment are equiva-
lent to processes, so that to each subject we can as-
sign a domain. Using domain transition, each subject
can be associated to different domains. Objects in a
DTE environment are resources to which we can as-
sign only one type. Thus, attributes in our scenario
are equivalent to domains for subjects and to types
for objects.
Table 2 shows the permissions assigned to particu-
lar subjects for reading, writing, or publishing the ob-
jects shown in the first column. For instance, the first
line expresses that subjects s1 to s225 (225 subjects)
are allowed to read objects o1 to o100 (100 objects).
This represents 225 · 100 = 22500 concrete rules. In
addition, subjects s201 to s225 (25 subjects) are al-
lowed to write objects o1 to o100 (100 objects) which
represent 25·100 = 2500 concrete rules; and subjects
s221 to s225 (five subjects) are allowed to publish ob-
jects o1 to o100 which represent 5 · 100 = 500 con-
crete rules. Following the same reasoning, we count
5250 rules for the second line, and 6250 rules for the
third line. This amounts to having 37000 concrete
rules in total.
Due to the difficulty in managing a policy with
225 subjects, 200 objects and 37000 rules, we stress
SECRYPT2015-InternationalConferenceonSecurityandCryptography
54
Table 1: Assignment of attributes.
(a) Subject-Attribute relationship.
Subject
Attributes
A1 A2 A3 A4 A5
[s
1
,s
100
] ×
[s
101
,s
130
] × ×
[s
131
,s
180
] × ×
[s
181
,s
200
] × × ×
[s
201
,s
220
] ×
[s
221
,s
225
] ×
A1: General news subscriber
A2: Sports news subscriber
A3: Economic news subscriber
A4: Contributor
A5: Publisher
(b) Object-Attribute relationship.
Object
Attributes
A6 A7 A8
[o
1
, o
100
] ×
[o
101
, o
150
] ×
[o
151
, o
200
] ×
A6: General news post
A7: Sports news post
A8: Economic news post
the need of quantitative metrics to assess the compre-
hensive complexity of such a policy.
To define metrics, regardless of the model, we for-
malize in the next section a set of assumptions that
summarize the basic concepts of authorization-based
access control models.
Table 2: Concrete Security Rules.
Object
Actions
read write publish
[o
1
, o
100
] [s
1
, s
225
] [s
201
, s
225
] [s
221
, s
225
]
[o
101
, o
150
]
[s
101
,s
130
],
[s
201
, s
225
] [s
221
, s
225
]
[s
181
,s
225
]
[o
151
, o
200
] [s
131
, s
225
] [s
201
, s
225
] [s
221
, s
225
]
3 BASICS OF
AUTHORIZATION-BASED
ACCESS CONTROL MODELS
Access control mechanisms are used for controlling
access rights to resources in a given organization.
Concretely, an access control rule indicates if a given
subject has the permission to perform an action on
a given object. Thus, an access control rule is com-
posed of a set of conditions (subject, action, object)
and a decision (e.g., allow or deny the action). Defi-
nitions 1 to 3 present common concepts of access con-
trol mechanisms.
Definition 1. Entities.
A subject is an entity (e.g., a person, a process,
a user account) to whom access to an object may be
granted. Let S be the set of subjects.
An object is a resource to which access may be
granted (e.g., a file or a directory). Let O be the set of
objects.
An action is an operation performed by a subject
over an object (e.g., read, write, execute). Let A be
the set of actions.
The above defined entities are also called concrete
entities because they concretely interact with the ac-
cess control mechanisms.
Definition 2. Access Control Decision.
There are two basic decisions for an access con-
trol request: allow or deny. We refer to the set of
access control decision as Z = {−1, 1}, where −1
means DENY and 1 means ALLOW.
In some authorization-based access control mod-
els, we find more than two access control decisions.
Nevertheless, the set of access control decisions is a
finite set.
Definition 3. Access Control Concrete Rule.
At the concrete level, an access control rule de-
scribes relations among subjects, actions, objects
and access control decisions. For instance, the rule
(s, α, o, 1) states that a subject s is allowed to perform
an action α on an object o.
We define, R
c
⊆ S × A × O as the set of concrete
access control rules in an access control model. n
Rc
=
|R
c
| is the number of concrete rules.
Since the number of concrete rules, n
Rc
, might in-
crease exponentially, the rule set becomes difficult to
manage and maintain. To solve this problem, access
control models introduce high-level statements to ex-
press access control rules. These statements consist of
an abstraction of conditions. This generally reduces
the number of expressed access control rules.
Definitions 4 to 8 define common high-level con-
cepts used in authorization-based access control mod-
els.
Definition 4. Abstraction of Conditions.
In an authorization-based access control model,
there exists at least one of the following abstractions
for concrete entities:
EvaluatingtheComprehensiveComplexityofAuthorization-basedAccessControlPoliciesusingQuantitativeMetrics
55
1. Abstraction of subjects: subjects are abstracted
using one or more of their attributes or using the
role they are playing in an organization. We call
Role
1
such an abstraction of subjects element. R
denotes the set of roles.
2. Abstraction of actions: actions are abstracted us-
ing one or more of their attributes or using the
role they are playing in the access control policy.
We call Activity
1
such an abstraction of actions
element. A denotes the set of activities.
3. Abstraction of objects: objects are abstracted us-
ing one or more attributes or using the role they
are playing in the access control policy. We call
View
1
such an abstraction of objects element. V
denotes the set of views.
Each of the above defined abstract entities are as-
sociated with one or more concrete elements.
After defining abstract entities, relations between
abstract and concrete entities are implicitly or explic-
itly expressed in the model.
Definition 5. Assignment Relations.
In an authorization-based access control model,
the association between concrete entities and abstract
entities is characterized by:
• SR
a
⊆ S × R , a many-to-many mapping of
subject-to-role assignment relation.
• AA
a
⊆ A × A, a many-to-many mapping of
action-to-activity assignment relation.
• OV
a
⊆ O × V , a many-to-many mapping of
object-to-view assignment relation.
Definition 6. Assigned Entities.
Let r ∈ R , then assigned
sub jects(r) = {s ∈
S|(s, r) ∈ SR
a
}, is the set of subjects assigned to the
role r.
Let a ∈ A, then assigned actions(a) = {α ∈
A|(α, a) ∈ AA
a
}, is the set of actions assigned to the
activity a.
Let v ∈ V , then assigned ob jects(v) = {o ∈
O|(o, v) ∈ OV
a
}, is the set of objects assigned to the
view v.
Using the abstraction of conditions, access control
rules are expressed differently. High-level statements
are translated to rules, but only conditions are ab-
stracted. Access control decisions are still unchanged
but they are applied to the abstract elements.
Definition 7. Abstract Access Control Rules.
At the abstract level, an access control rule de-
scribes the relation between abstract elements and ac-
cess control decisions.
1
The terms Role, Activity and View are used in the Or-
BAC model (Abou-El-Kalam et al., 2003).
Let r ∈ R ,a ∈ A, v ∈ V then the rule (r, a, v, 1)
states that subjects assigned to the role r are allowed
to perform actions abstracted by the activity a on ob-
jects assigned to the view v.
We define R
a
as the set of abstract rules in an ac-
cess control model, where n
R
a
= |R
a
| is the number of
abstract rules.
In authorization-based access control models, ab-
stract elements can be organized in a flat structure
(e.g., flat ABAC) or in a hierarchical structure (e.g.,
RBAC or OrBAC). In case of hierarchical structures
of abstract elements, we define the following defini-
tions.
Definition 8. Hierarchy Relations.
In an access control model, hierarchy relations
among abstract elements is characterized by:
• H
R
⊆ R × R , a many-to-many mapping of role-
to-role hierarchy relation.
• H
A
⊆ A × A, a many-to-many mapping of
activity-to-activity hierarchy relation.
• H
V
⊆ V × V , a many-to-many mapping of view-
to-view hierarchy relation.
Hierarchy structures are defined in authorization-
based access control models to simplify the policy
definition and management task by introducing the
concept of inheritance. We present this concept in the
following definition.
Definition 9. Inheritance of Rules.
Let (r
1
, r
2
) ∈ H
R
, then r
2
inherits all abstract
rules of r
1
. r
1
is called a super-role while r
2
is called
a sub-role.
Let (a
1
, a
2
) ∈ H
A
, then a
2
inherits all abstract
rules of a
1
. a
1
is called a super-activity while a
2
is
called a sub-activity.
Let (v
1
, v
2
) ∈ H
V
, then v
2
inherits all abstract
rules of v
1
. v
1
is called a super-view while v
2
is called
a sub-view.
In an access control model in which abstract el-
ements are hierarchically structured, access control
rules are divided in two groups: local rules and in-
herited rules.
Definition 10. Sets.
R
L
denotes the set of local abstract access control
rules. R
L
⊆ R
a
.
R
i
denotes the set of inherited abstract access con-
trol rules. R
i
⊆ R
a
.
In authorization-based access control models,
constraints are a powerful mechanism for laying out
a higher-level organizational policy. Constraints al-
low to regulate the policy management process by re-
specting some functional restrictions when writing or
modifying the policy.
SECRYPT2015-InternationalConferenceonSecurityandCryptography
56
Definition 11. Constraints.
Constraints are special rules over the entities and
relations of an authorization-based access control
model, that have to be respected when a security pol-
icy is designed.
Let C be the set of constraints.
Let c ∈ C , then, related entities(c) is the set of
entities affected by the constraint.
Most common constraints expressed in
authorization-based access control models are
separation constraints (e.g., roles R1 and R2 are
separated, meaning that a subject assigned to R1 can
not be assigned to R2, and vice versa), prerequisite
constraints, and cardinality constraints (e.g., only
four subjects can be assigned to role R1).
4 OUR PROPOSED METRICS
In this section, we define a consistent set of metrics
and measurements to evaluate the comprehensive
complexity of authorization-based access control
policies. Our metrics are constructions designed to
facilitate the decision making process for security
administrators by giving them information about
the comprehensive complexity of an access control
policy. They guide the administrators in the task of
optimizing the complexity of their access control
policies.
4.1 Complexity Definition
Before defining metrics to evaluate the complexity of
policies, we need to identify a useful definition for
complexity. This policy characteristic is ambiguous
and can be studied in several ways. The first type of
complexity is the computational complexity of a pol-
icy. For instance, it can be denoted as the cost for
a policy decision point to transform a policy into a
configuration file. The second type is the complexity
of policy execution. The complexity of executing the
policy can be seen as the complexity for a policy en-
forcement point to enforce a given policy. The third
type is the comprehensive complexity or the complex-
ity of understanding a policy by administrators. The
latter is the main focus of our study.
We define the comprehensive complexity of an ac-
cess control policy as the reasoning effort needed to
understand the policy by administrators in the pur-
pose of modifying it. If administrators understand
well the structure of the organization (entities, hier-
archy relations), the set of access control rules and
the constraints that regulate the policy, then, presum-
ably they should understand the effect of making a
change (Jaeger, 2001).
Comprehensiveness is improved with the abstrac-
tion of entities and the creation of hierarchy relations.
They reduce the number of entities and rules (some
rules and entities are inherited) and structure the pol-
icy elements. The use of hierarchy relations has two
effects. On the one hand, the use of hierarchy rela-
tions will reduce the number of local abstract rules.
This will reduce the comprehensive complexity (less
rules to understand). On the other hand, hierarchy
relations may also create additional reasoning effort
when analyzing a policy. We have to find the opti-
mum number of hierarchy relations to decrease the
complexity level of the access control policy.
Other structural aspect that could be consid-
ered to assess the comprehensive complexity of
authorization-based access control models are con-
straints. Depending on the type of the constraint, it
may affect all relations in the access control model.
The comprehensiveness of a constraint depends of the
number of policy elements affected by the constraint.
The complexity may also depend on the number of
functions used in the expression of the constraints
(e.g., cardinality and comparison). Thus, the com-
plexity measured for an access control policy may not
simply be the number of entities, rules and relation-
ships among entities, but also it depends on hierarchy
relations and constraints that regulate the policy.
4.2 Measurements
Based on the access control concepts formalized in
Section 3, we define a set of measurements that will
be used in our metric computation processes.
In the following, |X| denotes the cardinality of the
set X.
Definition 12. Number of Concrete Entities.
n
S
= |
S
∀r∈R
assigned sub jects(r)|, represents
the number of all assigned subjects in an access con-
trol policy.
n
A
= |
S
∀a∈A
assigned actions(a)|, represents the
number of all assigned actions in an access control
policy.
n
O
= |
S
∀v∈V
assigned ob jects(v)|, represents the
number of all assigned objects in an access control
policy.
n
cE
= n
S
+n
A
+n
O
, represents the number of con-
crete entities in an access control policy.
Definition 13. Number of Abstract Entities.
Let A
s
= 1, if the access control model implements
an abstraction of subjects.
n
R
= |R |, represents the number of roles in an access
EvaluatingtheComprehensiveComplexityofAuthorization-basedAccessControlPoliciesusingQuantitativeMetrics
57
control policy.
If the model does not implement an abstraction of sub-
jects, then A
s
= 0 and n
R
= 0.
Let A
α
= 1, if the access control model implements
an abstraction of actions.
n
A
= |A|, represents the number of activities in an ac-
cess control policy.
If the model does not implement an abstraction of ac-
tions, then A
α
= 0 and n
A
= 0.
Let A
o
= 1, if the access control model implements
an abstraction of objects.
n
V
= |V |, represents the number of views in an ac-
cess control policy.
If the model does not implement an abstraction of ob-
jects, then A
o
= 0 and n
O
= 0.
n
aE
= n
R
+n
A
+n
V
, represents the number of ab-
stract elements in an access control policy.
n
H
= |H
R
| + |H
A
| + |H
V
|, represents the number
of hierarchy relations in an access control policy.
n
G
= |S R
a
|+|AA
a
|+|OV
a
|, represents the num-
ber of assignment relations in access control policy.
Definition 14. Number of Rules.
n
Rc
= |R
c
|, represents the number of concrete
rules in an access control policy.
n
Ra
= |R
a
|, represents the number of abstract
rules in an access control policy.
n
RL
= |R
L
|, represents the number of local ab-
stract rules in an access control policy.
n
Ri
= |R
i
|, represents the number of inherited ab-
stract rules in an access control policy.
n
Ra
= n
RL
+ n
Ri
Definition 15. Measurements for Constraints.
n
C
= |C|, represents the number of constraints in
access control policy.
Let c ∈ C , then, n
rC
(c) = |related entities(c)| rep-
resents the number of entities affected by the con-
straint c and n
fC
(c) represents the number of func-
tions used in the expression of the constraints c.
4.3 Abstraction Metrics
After defining different measurements related to an
access control policy, we propose a set of metrics to
evaluate the complexity of a policy.
Metric 1: Abstraction of Rules
An access control model adds high-level state-
ments to reduce the number of rules. The higher the
number of security rules, the higher the complexity of
the policy. We propose to calculate the ratio between
abstract rules and concrete rules as an indicator for
policy complexity.
M
1
=
n
Ra
n
Rc
(1)
• if M
1
> 1, then the number of abstract rules n
Ra
exceeds the number of concrete rules n
Rc
. The
abstraction is not well defined. The access control
model increases the complexity of the policy.
• if M
1
→ 1, then the number of abstract rules n
Ra
is approximately equal to the number of concrete
rules n
Rc
. The abstraction does not reduce the
number of rules. The policy is complex or triv-
ial (if the n
Rc
is small).
• if M
1
→ 0, then the abstraction reduces the num-
ber of rules. The policy is easy to understand. It
is more expressive.
Metric 2: Abstraction of Entities
An access control model, by introducing an ab-
straction for conditions, reduces the complexity of the
policy. An access control policy expressed with less
entities is easier to understand for administrators. We
propose to calculate the ratio between abstract entities
and concrete entities as an indicator for policy com-
plexity.
M
2
=
A
s
· n
R
+ A
α
· n
A
+ A
o
· n
V
A
s
· n
S
+ A
α
· n
A
+ A
o
· n
O
(2)
• if M
2
> 1, then the number of abstract entities ex-
ceeds the number of concrete entities. The ab-
straction is not well defined. This may be due to
the existence shadowed roles, activities or views.
• if M
2
→ 1, then the number of abstract entities
is approximately equal to the number of concrete
entities. The abstraction does not reduce the num-
ber of entities. The policy is complex (existence
of shadowed roles, activities or views) or trivial (if
the number of concrete entities n
cE
is small).
• if M
2
→ 0, then the abstraction reduces the num-
ber of entities. The policy is easy to understand.
Abstract entities are expressive.
4.4 Complexity Metric
To understand the policy, an administrator has to un-
derstand each entity, each access control rule, each
hierarchy relation, each assignment relation, and each
constraint. In (Jaeger, 2001), the complexity of policy
elements is expected to depend on how many types of
information must be understood.
Before defining the comprehensive complexity of
a policy, we propose a metric to assess the complex-
ity of constraints. In (Jaeger, 2001) the complexity
of a constraint depends not only on number of pol-
icy elements affected by the constraint but also on the
number of functions that must be computed to verify
the constraint. Thus, a large number of related entities
SECRYPT2015-InternationalConferenceonSecurityandCryptography
58
and used functions may indicate an increased reason-
ing effort for adding new policy elements because the
consistency checks are more complex. We introduce
M
C
(c) as the comprehensive complexity for a given
constraint c ∈ C :
M
C
(c) = n
rC
(c) +n
fC
(c)
For each policy element, we propose to affect
a model-dependent weight which would reflect the
comprehensive complexity of the element:
• w
E
: the complexity weight of each concrete or ab-
stract entity.
• w
L
: the complexity weight of each local access
rule.
• w
i
: the complexity weight of each inherited access
control rule.
• w
H
: the complexity weight of each hierarchy re-
lation.
• w
A
: the complexity weight of each assignment re-
lation.
To compute the complexity weights, we leverage
from (Miller, 1956), and assume that people think
effectively in terms of chunks of information. For
instance, in programing the use of code blocks en-
able programmers to convert programs in to high level
concepts such as functions that represent their seman-
tic intents. As the complexity of a particular pro-
gram increases, the programmers need to create use-
ful chunks to reduce it. Thus, they must re-learn com-
plex each time that they need to use these chunks.
This way, for authorization based access control mod-
els, the elementary chunks of information are the el-
ements of the policy: concrete entities, abstract en-
tities, rules, hierarchy relations and assignment re-
lations. However, we suppose that the complexity
of policy elements are not always equal. Given that
different information are stored in each policy ele-
ment, we assume that their complexity depends on
how many types of information must be understood
from the element to perform an operation.
Based on the aforementioned assumptions, we
evaluate the policy complexity by a weighted sum of
policy elements, as expressed in Equation 3.
M
3
= w
E
· n
cE
+ w
E
· n
aE
+ w
L
· n
RL
+ w
i
· n
Ri
+
w
H
· n
H
+ w
A
· n
G
+
∑
c∈C
M
C
(c)
(3)
5 EVALUATION
5.1 Applying the Metrics
In order to evaluate our metrics, we compute the com-
plexity metrics for the example defined in Section 2.
We propose to use high-level access control models
in order to express the scenario of the example. In
the following, we express the policy using the RBAC
model and the ABAC model. For each access control
model, we determine the complexity weights used in
the complexity metric, M
3
(cf. Section 4.4). Finally,
we compute the metrics proposed in Section 4 for the
resulting policies.
5.1.1 RBAC Model
The RBAC model uses an abstraction of subjects,
based on the role each subject is playing in the orga-
nization. In our scenario, we group actors by the role
they have in the CMS. Thus, we have five possible
roles in our scenario: General news subscribers (R1),
Sports news subscribers (R2), Economic news sub-
scribers (R3), Contributors (R4) and Publishers (R5).
Table 3: RBAC.
(a) Subject-Role assignments.
Subject
Roles
R1 R2 R3 R4 R5
[s
1
,s
100
] ×
[s
101
,s
130
] ×
[s
131
,s
180
] ×
[s
181
,s
200
] × ×
[s
201
,s
220
] ×
[s
221
,s
225
] ×
R1: General news subscriber role
R2: Sports news subscriber role
R3: Economic news subscriber role
R4: Contributor role
R5: Publisher role
(b) RBAC abstract rules.
Object
Actions
read write publish
[o
1
, o
100
] R1,R2,R3,R4,R5 R4,R5 R5
[o
101
, o
150
] R2,R4,R5 R4,R5 R5
[o
151
, o
200
] R3,R4,R5 R4,R5 R5
Table 3a shows the subject-role assignments.
Each cell of the table represents the assignment of a
group of subject to a specific role. In the first cell (first
line, first column) of Table 3a subject s
1
to s
100
(100
EvaluatingtheComprehensiveComplexityofAuthorization-basedAccessControlPoliciesusingQuantitativeMetrics
59
subjects) are assigned to role R1. The first cell of the
table represents 1 · 100 = 100 assignment relations.
Following the same reasoning, the first line expresses
100 assignment relations, the second line 30, the third
line 50, the fourth line 40, the fifth 20 and the sixth
5. This amounts to having a total of 245 assignment
relations for this RBAC policy (n
G
= 245).
Using the abstraction presented in the RBAC
model, the permissions will be assigned to roles.
Then, a subject assigned to a role will have all the
permissions assigned to such role.
In the description of the scenario (cf. Section 2),
we indicate that a subject could not be a contributor
and a publisher at the same time. This functional re-
striction could be translated to a separation constraint
(C1) over the roles R4 (Contributors) and R5 (Pub-
lishers).
Table 3b presents the RBAC access control rules.
Each cell of the table represents a specific access per-
formed on a given set of posts. When we place a role
in a cell, it means that the role has the permission to
perform the action (given by the column) on objects
(given by the line).
In the first cell (first line, first column) of Table 3b,
roles R1 to R5 (five roles) are allowed to read objects
o
1
to o
100
(100 objects). The first cell of the table
represents 5 · 100 = 500 abstract rules. Following the
same reasoning, the first line expresses 800 abstract
rules, the second line 300, and the third line another
300. This amounts to having a total of 1400 abstract
rules for this RBAC policy (n
Ra
= 1400). This num-
ber will not increase if we increase the number of sub-
jects. However, it will increase if we add new posts
(objects) to the CMS.
The metric M3 applied to the RBAC model will
have the following weights:
• w
E
= 1. For an entity, we have to understand only
the information given by the node.
• w
L
= 4. For an abstract rule in the RBAC model,
we have to understand the three elements (role,
action, object) and the conclusion that compose
the rule.
• w
i
= 0 and w
H
= 0. Hierarchy relations are not
defined in the RBAC model.
• w
A
= 2. For and assignment relation, we have to
understand two elements (abstract entity, concrete
entity).
If we compute the metrics proposed in Section 4
for this RBAC policy, we have the following values:
• n
aE
= 5, n
cE
= 428, n
Ra
= n
RL
= 1400, n
Ri
= 0,
n
Rc
= 37000, n
H
= 0, n
G
= 425
• M
C
(C1) = 2 + 1 = 3, to understand the constraint
C1, an administrator has to understand the two
roles (R4 and R5) and the function that verifies
if the two roles are separated (comparison of sets
function).
• M1
RBAC
=
n
Ra
n
Rc
=
1400
37000
= 0.038.
• M2
RBAC
=
n
R
n
S
=
5
225
= 0.022.
• M3
RBAC
= 1 · n
cE
+ 1 · n
aE
+ 4 · n
RL
+ 2 · n
G
+
M
C
(C1) = 6526
M1
RBAC
→ 0, M2
RBAC
→ 0 The abstraction is well
defined. The policy is easy to understand.
5.1.2 Hierarchical RBAC Model
As described in the scenario, any subject subscribed
to the Sports news or Economic news is automati-
cally subscribed to General news. In other words,
the Sports news subscribers and the Economic news
subscribers inherit the access of General news sub-
scribers. Therefore, we can introduce a hierarchy re-
lation in terms of the RBAC model that reflects this
situation. General news subscribers (R1) is a super-
role for Sports news subscribers (R2) and Economic
news subscribers (R3). This means that R2 and R3
inherit all the permissions of R1.
In addition, Publishers (R5) have the same rights
as Contributors (R4), plus an additional right which is
to publish posts. We can, then, introduce a hierarchy
relation to model this situation. R4 is a super-role for
R5, which means that R5 inherits all the permissions
of R4.
With the introduction of the hierarchy concept, the
abstract rule set changes. Table 4 describes the new
abstract access control rules in an RBAC-Hierarchical
model.
Table 4: RBAC-Hierarchical abstract rules table.
Object
Actions
read write publish
[o
1
, o
100
] R1,R2*,R3*,R4,R5* R4,R5* R5
[o
101
, o
150
] R2,R4,R5* R4,R5* R5
[o
151
, o
200
] R3,R4,R5* R4,R5* R5
*: For inherited rules
Table 4 presents the RBAC access control rules
after the introduction of the hierarchy relation. Each
cell of the table represents a specific access performed
on a given set of posts. When we place a role in a cell,
it means that the role has the permission to perform
the action (given by the column) on objects (given by
line). We add the asterisk symbol (i.e., symbol *) for
inherited permissions.
In the first cell (first line, first column) of Table 4,
roles R1 and R4 (2 roles) are allowed to read objects
o
1
to o
100
(100 objects). Roles R2, R3 and R5 (3
SECRYPT2015-InternationalConferenceonSecurityandCryptography
60
roles) inherit the permission to read objects o
1
to o
100
(100 objects). The first cell of the table represents
2 · 100 = 200 local abstract rules and 3 · 100 = 300
inherited rules. Following the same reasoning, we
count 1400 abstract rules for this Hierarchical-RBAC
policy (n
Ra
= 1400). The abstract rules are com-
posed of 800 local rules (n
RL
= 800) and 600 inherited
rules(n
Ri
= 600).
The metric M3 applied to the Hierarchical-RBAC
model will have the following weights:
• w
E
= 1 (cf. Section 5.1.1 for more details).
• w
L
= 4 (cf. Section 5.1.1 for more details).
• w
i
= 1. An inherited rule has the same elements as
those associated to the local rule except for one el-
ement (the role). Thus, to understand an inherited
rule, it suffices to understand such an element.
• w
H
= 2. Each role hierarchy relation involves two
roles. Understanding a role hierarchy relation re-
lies on understanding the two entities involved in
such hierarchy relations.
• w
A
= 2 (cf. Section 5.1.1 for more details).
If we compute the metrics proposed in Section 4
for this example, we get the following values for the
Hierarchical-RBAC policy summarized in Table 4:
• n
aE
= 5, n
cE
= 428, n
Ra
= 1400, n
RL
= 800, n
Ri
=
600, n
Rc
= 37000, n
H
= 3, n
G
= 245
• M
C
(C1) = 2 + 1 = 3 (cf. Section 5.1.1 for more
details).
• M1
H−RBAC
=
n
Ra
n
Rc
=
1400
37000
= 0.038
• M2
H−RBAC
=
n
R
n
S
=
5
225
= 0.022
• M3
H−RBAC
= 1 · n
cE
+ 1 · n
aE
+ 4 · n
RL
+ 1 · n
Ri
+
2 ·n
G
+ 2 · n
H
+ M
C
(C1) = 4732
We note that M3
H−RBAC
< M3
RBAC
. We conclude
that M3 is a relative metric. By introducing hierarchy
relations, the complexity has been reduced from 6526
to 4732.
Indeed, the RBAC model reduces the number of
rules with the introduction of the subject abstraction.
The results can be improved if we abstract, as well
as, the object entities. In the sequel, we show such an
improvement.
5.1.3 ABAC Model
The ABAC model uses an abstraction of subjects and
objects, based on their attributes. The access control
rules are written using attributes. Each abstract rule
states that all subjects that have a given subject at-
tribute are allowed to perform an action α on those
objects that have a given object attribute. For instance,
in our scenario, we could state that those subjects with
attribute A5 (Publisher) are allowed to publish objects
with attribute A6 (General news post).
In the description of the scenario (section 2), we
indicate that a subject could not be a contributor and a
publisher at the same time. This functional restriction
could be translated to a separation constraint(C1) over
the attributes A4 (Contributors) and A5 (Publishers).
Another functional restriction is that a post could only
have one attribute (A6, A7 or A8). This latter could
be translated to a separation constraint over attributes
A6, A7 and A8.
Table 5 presents the ABAC access control rules.
Each cell of the table represents a specific access per-
formed on posts having the attribute given by the line.
When we place a subject attribute in a cell, it means
that the subjects having this attribute have the permis-
sion to perform the action (given by the columns) on
objects having the attribute given by the line.
Table 5: ABAC abstract rules.
Object
Actions
read write publish
A6 A1,A2,A3,A4,A5 A4,A5 A5
A7 A2,A4,A5 A4,A5 A5
A8 A3,A4,A5 A4,A5 A5
In the first cell (first line, first column) of Table 5,
subjects with attributes A1 to A5 (five attributes) are
allowed to read objects having the attribute A6 (one
attribute). The first cell of the table represents 5 ·1 = 5
abstract rules. Following the same reasoning, the first
line expresses a total of eight abstract rules. The sec-
ond line expresses six abstract rule. The third line
expresses another six abstract rules. This amounts to
having a total of abstract rules for this ABAC policy
(n
Ra
= 20). We conclude that with an abstraction of
both subjects and objects, the number of abstract rules
has dramatically decreased compared to the RBAC
policies.
The metric M3 applied to the ABAC model will
have the following weights:
• w
E
= 1 (cf. Section 5.1.1 for more details).
• w
L
= 4. For an abstract rule in the ABAC model,
we have to understand the three elements (subject
attribute, action, object attribute) and the conclu-
sion that compose the rule.
• w
i
= 0 and w
H
= 0 (cf. Section 5.1.1 for more
details).
• w
A
= 2 (cf. Section 5.1.1 for more details).
The metrics proposed in Section 4 calculated for
this ABAC policy, give the following values:
• n
aE
= 8, n
cE
= 428, n
Ra
= n
RL
= 20, n
Ri
= 0,
n
Rc
= 37000, n
H
= 0.
EvaluatingtheComprehensiveComplexityofAuthorization-basedAccessControlPoliciesusingQuantitativeMetrics
61
• n
G
= 545, the number of assignment relations is
computed using the same reasoning adopted in
Section 5.1.1 over the elements of Table 1a and
Table 1b.
• M
C
(C1) = 2 + 1 = 3 (cf. Section 5.1.1 for more
details).
• M
C
(C2) = 3 + 1 = 4, to understand the constraint
C2, an administrator has to understand the three
attributes (A6, A7 and A8) and the function that
verifies if the three attributes are separated (com-
parison of sets function).
• M1
ABAC
=
n
Ra
n
Rc
=
20
37000
= 5.4 · 10
−4
• M2
ABAC
=
n
R
+n
V
n
S
+n
O
=
5+3
225+200
= 0.019
• M3
ABAC
= 1 · n
cE
+ 1 · n
aE
+ 4 · n
RL
+ 2 · n
G
+
M
C
(C1) + M
C
(C2) = 1613
Notice that M3
ABAC
M3
RBAC
. Therefore, we
conclude that the more abstraction level we add, the
more we reduce the complexity of the policy.
5.2 Discussion
The values of the proposed metrics computed in Sec-
tion 5.1 confirm the definition of complexity pre-
sented in Section 4.1. For the RBAC policy and
the hierarchical RBAC policy, we observe that hi-
erarchy relations reduce the complexity of policies
(M3
H−RBAC
< M3
RBAC
). We also note that M
1
and
M
2
do not take into consideration the hierarchy re-
lations. In other words, their values do not change.
For the ABAC policy, the values of M
1
and M
2
were
improved because the ABAC model introduces an ab-
straction of objects in addition to the abstraction of
subjects used in the RBAC model.
The results are confirmed in practice. Indeed, to
add a new subject to the ABAC or RBAC policy, it is
equivalent to creating the subject and assigning it to a
role (for RBAC) or an attribute (for ABAC). Then,
the ABAC and RBAC cases would have the same
complexity. The process is not the same for objects.
Adding a new object in the RBAC policy is equivalent
to (1) creating the object and (2) adding all the needed
permissions to those roles that shall manipulate it. On
the contrary, in the ABAC policy, administrators only
need to create the object and assign to it the attributes.
Therefore, it is fair to say that the complexity is not
the same for the ABAC and RBAC policies.
To reinforce the above remarks, we can also com-
pute the metrics upon the same scenario, but changing
the number of subjects and number of objects. As-
sume, for instance, the following two newspaper ex-
amples: in the first one, the number of subscribers
largely exceeds the number of contributors; in the sec-
ond one, subjects are at the same time subscribers and
contributors. In the first case, the computed complex-
ity metrics would give the following values for the
RBAC policy:
• n
aE
= 5, n
S
= 10
5
, n
A
= 3, n
O
= 200, n
cE
=
100203, n
Ra
= n
RL
= 1400, n
Ri
= 0, n
Rc
≈ 10
7
,
n
H
= 0, M
C
(C1) = 3
• M1
RBAC
=
n
Ra
n
Rc
=
1400
10
7
= 0.14 · 10
−5
• M2
RBAC
=
n
R
n
S
=
5
10
5
= 5 · 10
−5
• M3
RBAC
= 1 · n
cE
+ 1 · n
aE
+ 4 · n
RL
+ 2 · n
G
+
M
C
(C1) = 105811
We notice that the abstraction is well defined
(M
1
→ 0, M
2
→ 0). We also notice that the com-
plexity increases, since M
3
takes into consideration
the number of concrete entities.
In the second case, the computed complexity met-
rics, give the following values for the RBAC policy:
• n
aE
= 5, n
S
= 1000, n
A
= 3, n
O
= 200, n
cE
=
1203, n
Ra
= n
RL
= 1400, n
Ri
= 0, n
Rc
≈ 10
5
,
n
H
= 0, M
C
(C1) = 3
• M1
RBAC
=
n
Ra
n
Rc
=
1400
10
5
= 0.14 · 10
−5
• M2
RBAC
=
n
R
n
S
=
5
1203
= 0.41 · 10
−2
• M3
RBAC
= 1 · n
cE
+ 1 · n
aE
+ 4 · n
RL
+ 2 · n
G
+
M
C
(C1) = 6811
We notice that the abstraction is well defined
(M
1
→ 0, M
2
→ 0). We also notice that the com-
plexity M
3
decreases compared to the first case, since
there are less subjects.
5.3 Testbed based on SELinux Policies
To validate our approach, a proof-of-concept has been
developed based on Lil CMS (Lil CMS — The Eas-
iest Content Management System, 2014). Lil CMS
is a simple content management system that allows
users to remotely change the content of a Web server.
The contents in Lil CMS are stored in plain text
files. Lil CMS is easy to integrate with any tra-
ditional LAMP (Linux, Apache, MySQL and PHP)
Web server. Our proof-of-concept, available at (Bel-
haouane et al., 2015), allows us computing the set
of metrics described in this paper, upon our adapted
version of Lil CMS (assumed to be administered via
SELinux policies on a Web server). Our proof-of-
concept provides some representative SELinux (Se-
curity Enhanced Linux (McCarty, 2004; Mayer et al.,
2006)) policies, described according to the different
SELinux access control models, and with the purpose
of putting in practice the metrics defined in Section 4.
SECRYPT2015-InternationalConferenceonSecurityandCryptography
62
The SELinux access control mechanism is primar-
ily based on the TE (type enforcement) (Badger et al.,
1995) model. TE associates each process with a do-
main and each non-process object with a type. Per-
missions are encoded as access vectors, which specify
the operations that processes of a domain are autho-
rized to perform on objects of a given type, such as
files. Thus, an object’s type can be considered as an
abstraction element for objects and a domain as an ab-
straction element of related processes. The TE access
control mechanism implemented in SELinux can be
compared to an ABAC model but with the constraint
that entities (e.g., processes and files) can have only
one attribute (type). SELinux can also implement a
second access control model, called SELinux role-
based access control (RBAC). The SELinux RBAC
feature is, in turn, built upon TE. Indeed, the access
control in SELinux will be conducted via TE.
Using the aforementioned concepts on SELinux,
we provide in our proof-of-concept some descriptive
policy examples for our adapted version of Lil CMS
— expected to be controlled by SELinux modules in
a LAMP Web server. We evaluated and tested similar
policies as those described in Section 5.1. Two main
types of SELinux policies are defined. The first type
uses only TE access control mechanisms to imple-
ment the CMS policies. The second type uses RBAC
upon TE to implement the CMS policies. The aim
of our proof-of-concept is the evaluation of such poli-
cies, in terms of their understanding complexity by
SELinux administrators. At the same time, the series
of policies defined in our proof-of-concept are also of
value in order to evaluate other kinds of complexity
measures (e.g., the computational complexity of the
policy or the complexity of executing such policies
by the Web server).
6 RELATED WORK
Several propositions in the complexity of access con-
trol policies have been presented. Research in this
field includes computational complexity (Colantonio
et al., 2010), size and structure of policies (Vaidya
et al., 2010; Beckerle and Martucci, 2013), perfor-
mance measure for evaluating the complexity of pol-
icy execution (Kateb et al., 2012), or comprehensive
complexity by evaluating maintenance effort (Jaeger,
2001). The work in (Colantonio et al., 2010) studies
the effort for the computation of an RBAC model by
examining the complexity of role mining algorithms.
The approach in (Beckerle and Martucci, 2013) high-
lights that complexity is a major problem in the man-
ageability of access control policies. They confirm
that the size of an access control policy impact the
complexity. They proposed, for instance, the number
of policy elements as a metric to evaluate the com-
plexity. Furthermore, results in (Kateb et al., 2012)
confirm that the increasing number of an access con-
trol model elements can cause performance issues and
impacts the execution complexity. In contrast, the
work in (Jaeger, 2001) defines the complexity of ac-
cess control models as the complexity of understand-
ing the model by administrators in order to create and
maintain access control policies. Similar to Jaeger,
we define the complexity of authorization-based ac-
cess control models as the effort required to under-
stand the model.
Our work is related to previous contributions
from the area of complexity measurement for
authorization-based access control models. This way,
complexity measurement may help to optimize and
refactor access control policies to simplify the policy
administration process (Beckerle and Martucci, 2013;
Kateb et al., 2012). The previous work only focuses
on the size and structure of an access control model
to evaluate the complexity. Our work complements
this stream of research with a set of metrics that can
be used in policy optimization process with respect to
reasoning effort.
7 CONCLUSION
We introduced a series of metrics that evaluate the
comprehensive complexity of understanding an ac-
cess control policy. We started by describing a con-
crete example about the policy complexity concept.
We then formalized basic concepts of authorization-
based access control models, and presented our defi-
nition of policy complexity. Based on our definition,
we provided a set of metrics to evaluate such a char-
acteristic. The provided metrics were validated via a
content management system (CMS) policy example.
The approach has also been validated on a real envi-
ronment using a general-purpose CMS controlled by
SELinux (Security Enhanced Linux) policies. The re-
sults indicate that our metrics give a real estimation
of the complexity of policies. Our metrics provide a
tool for evaluating the complexity of understanding a
policy by administrators. In addition, our metrics can
be used in the optimization processes for generating
simpler and error-free access control policies. Future
work aims at improving the proposed metrics and ex-
tend them for contextual access control policies. An-
other objective is to propose strategies for analyzing
alternative policies using metrics.
EvaluatingtheComprehensiveComplexityofAuthorization-basedAccessControlPoliciesusingQuantitativeMetrics
63
ACKNOWLEDGEMENTS
Authors acknowledge support from the EC Frame-
work Program, under the PANOPTESEC project (GA
610416), as well as Spanish Ministry of Science
and Innovation (project TIN2011-27076-C03-02 CO-
PRIVACY).
REFERENCES
Abou-El-Kalam, A., Baida, R., Balbiani, P., Benferhat, S.,
Cuppens, F., Deswarte, Y., Mi
`
ege, A., Saurel, C.,
and Trouessin, G. (2003). Organization Based Ac-
cess Control. In IEEE 4th International Workshop on
Policies for Distributed Systems and Networks (Policy
2003), pages 120–131. IEEE Computer Society.
Badger, L., Sterne, D. F., Sherman, D. L., and Walker, K. M.
(1996). A domain and type enforcement UNIX proto-
type. Computing Systems, 9(1):47–83.
Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M.,
and Haghighat, S. A. (1995). Practical domain and
type enforcement for UNIX. In Security and Privacy,
1995. Proceedings., 1995 IEEE Symposium on, pages
66–77. IEEE.
Beckerle, M. and Martucci, L. A. (2013). Formal Defini-
tions for Usable Access Control Rule Sets From Goals
to Metrics. In Ninth Symposium on Usable Privacy
and Security (SOUPS 2013), pages 1–11. ACM.
Belhaouane, M., Debar, H., and Garcia-Alfaro, J. (Last
Access: 2015). Evaluating the Complexity of Ac-
cess Control Policies Using Quantitative Metrics –
SELinux Testbed Repository (Appendix). [On-line].
Available at https://github.com/met-testbeds/selinux.
Colantonio, A., Pietro, R. D., Ocello, A., and Verde, N. V.
(2010). Taming role mining complexity in RBAC.
Computers & Security, 29(5):548–564.
Cuppens, F., Cuppens-Boulahia, N., and Ben Ghorbel, M.
(2007). High Level Conflict Management Strategies in
Advanced Access Control Models. Electronic Notes
in Theoretical Computer Science, 186:3–26.
Garcia-Alfaro, J., Boulahia-Cuppens, N., and Cuppens, F.
(2008). Complete analysis of configuration rules to
guarantee reliable network security policies. Int. J.
Inf. Sec., 7(2):103–122.
Garcia-Alfaro, J., Cuppens, F., and Cuppens-Boulahia, N.
(2006). Analysis of policy anomalies on distributed
network security setups. In Computer Security - ES-
ORICS 2006, 11th European Symposium on Research
in Computer Security, Hamburg, Germany, September
18-20, 2006, Proceedings, pages 496–511.
Garcia-Alfaro, J., Cuppens, F., and Cuppens-Boulahia, N.
(2007). Management of Exceptions on Access Con-
trol Policies. In 22nd IFIP TC-11 International Infor-
mation Security Conference (IFIP SEC 2007), pages
97–108.
Garcia-Alfaro, J., Cuppens, F., Cuppens-Boulahia, N.,
Mart
´
ınez Perez, S., and Cabot, J. (2013). Manage-
ment of stateful firewall misconfiguration. Computers
& Security, 39:64–85.
Harrison, M. A., Ruzzo, W. L., and Ullman, J. D. (1976).
Protection in operating systems. Commun. ACM,
19(8):461–471.
Jaeger, T. (2001). Managing Access Control Complex-
ity Using Metrics. In Sixth ACM Symposium on Ac-
cess Control Models and Technologies (SACMAT-01),
pages 131–152.
Kateb, D. E., Mouelhi, T., Traon, Y. L., Hwang, J., and Xie,
T. (2012). Refactoring access control policies for per-
formance improvement. In Third Joint WOSP/SIPEW
International Conference on Performance Engineer-
ing, ICPE’12, Boston, MA, USA - April 22 - 25, 2012,
pages 323–334.
Lampson, B. W. (1969). Dynamic protection structures. In
AFIPS Fall Joint Computing Conference, pages 27–
38.
Lampson, B. W. (1974). Protection. Operating Systems
Review, 8(1):18–24.
Lil CMS — The Easiest Content Management System (Last
Access: 2014). Available at http://www.lilcms.com/.
Martin, E., Xie, T., and Yu, T. (2006). Defining and Measur-
ing Policy Coverage in Testing Access Control Poli-
cies. In 2006 International Conference on Informa-
tion and Communications Security (ICICS ’06), pages
139–158. Springer.
Mayer, F., MacMillan, K., and Caplan, D. (2006). SELinux
by Example: Using Security Enhanced Linux (Pren-
tice Hall Open Source Software Development Series).
Prentice Hall PTR, Upper Saddle River, NJ, USA.
McCarty, B. (2004). SELinux: NSA’s Open Source Security
Enhanced Linux. O’Reilly Media, Inc.
Miller, G. A. (1956). The magical number seven, plus or
minus two: some limits on our capacity for processing
information. Psychological Review, 63:81–97.
Samarati, P. and De Capitani di Vimercati, S. (2000). Ac-
cess control: Policies, models, and mechanisms. In
FOSAD, pages 137–196.
Sandhu, R. S., Coyne, E. J., Feinstein, H. L., and Youman,
C. E. (1996). Role-based access control models. IEEE
Computer, 29(2):38–47.
The Drupal project (Last Access: 2015). Available at
http://drupal.org/.
Vaidya, J., Atluri, V., and Guo, Q. (2010). The role mining
problem: A formal perspective. ACM Trans. Inf. Syst.
Secur., 13(3).
Wordpress Web Site (Last Access: 2015). Available at
http://wordpress.com/.
Yuan, E. and Tong, J. (2005). Attributed Based Access Con-
trol (ABAC) for Web Services. In 2005 IEEE Interna-
tional Conference on Web Services, pages 561–569.
SECRYPT2015-InternationalConferenceonSecurityandCryptography
64
