A Logical Specification and Analysis for SELinux MLS
Policy
Boniface Hicks, Sandra Rueda, Luke St.Clair, Trent Jaeger, and Patrick McDaniel
Systems and Internet Infrastructure Security Laboratory
The Pennsylvania State University
University Park, PA, 16802
{phicks,ruedarod,lstclair,tjaeger,mcdaniel}@cse.psu.edu
ABSTRACT
The SELinux mandatory access control (MAC) p olicy has
recently added a multi-level security (MLS) model which
is able to express a fine granularity of control over a sub-
ject’s access rights. The problem is that the richness of
this policy makes it impractical to verify, by hand, that a
given policy has certain important information flow proper-
ties or is compliant with another policy. To address this, we
have modeled the SELinux MLS policy using a logical spec-
ification and implemented that specification in the Prolog
language. Furthermore, we have developed some analyses
for testing the properties of a given policy as well an al-
gorithm to determine whether one policy is compliant with
another. We have implemented these analyses in Prolog and
compiled our implementation into a tool for SELinux MLS
policy analysis, called PALMS. Using PALMS, we verified
some important properties of the SELinux MLS reference
policy, namely that it satisfies the simple security condition
and ?-property defined by Bell and LaPadula [2].
Categories and Subject Descriptors
K.6.5 [Management of Computing and Information
Systems]: Security and Protection; D.4.6 [Operating Sys-
tems]: Security and Protection—information flow controls
General Terms
Security, Languages, Verification
Keywords
SELinux, multi-level security, p olicy compliance, policy anal-
ysis
1. INTRODUCTION
SELinux seeks to fully specify the principle of least privi-
lege on modern operating systems using a mandatory access
control (MAC) security policy. To accomplish this goal, the
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SACMAT’07, June 20-22, 2007, Sophia Antipolis, France.
Copyright 2007 ACM 978-1-59593-745-2/07/0006 ...$5.00.
SELinux policy system has combined three different policy
mo dels: Role-based Access Control (RBAC), Type Enforce-
ment (TE) and multi-level security (MLS).
While the TE policy can be used to control the integrity
of information flows [10] (i.e. where information flows from),
an MLS policy is designed to control the confidentiality of
information flows (i.e. where informatin flows to). In par-
ticular, an MLS policy is meant to prevent the leakage of in-
formation from more secret sources to less secret channels.
Protecting against such a leakage of information is espe-
cially important to nearly all government and military sec-
tors, who widely use the MLS model. With the widespread
o ccurrence of electronic data theft, costing individuals and
institutions billions of dollars in damages and lawsuits, MLS
policies may find increasing use in other sectors as well.
Perhaps anticipating such a broad usage, the MLS policy
language in SELinux is general enough to express a wide va-
riety of confidentiality policies. The problem is that the MLS
policy language is so broad that it is not easy to determine
exactly what information flow goals are enf orced by a given
policy. For example, in a given policy, it is important to
know that all possible information flows are constrained by
the policy (there should be no unconstrained way to read or
write data). Also, it may be important to know that the pol-
icy faithfully implements standard high-level goals, such as
the simple security condition (no read-up) or the ?-property
(no write-down) as defined by Bell and LaPadula [2]. Fi-
nally, there are cases in which it is valuable to know that
one MLS policy is compliant w ith another. For example,
in a distributed system when a new machine joins a trusted
group it is important to determine that the new machine will
faithfully enforce the policy goals of the group [11]. Thus a
policy compliance test is warranted.
Performing such an analysis is not easy, however. The
standard reference policy contains hundreds of lines of policy
statements, constraining access of some 40 kernel objects
that may be accessed in almost 50 modes. A manual analysis
of this policy in impractical. This is further complicated by
the lack of a logical presentation of the semantics of the
policy. While the RBAC and TE models have existed in
SELinux for many years and have been studied at length [5,
9, 10, 19, 17, 24], the MLS model in SELinux is quite new [6].
Since the MLS model is largely orthogonal to the TE model,
existing analyses for TE cannot be applied to it. What is
still needed are a formal policy semantics by which we can
reason about MLS policy and an analysis tool to aid in this
pro ces s.
91