Multilevel Classification in SELinux - Masaryk University


Dec 9, 2013 (3 years and 4 months ago)


Masaryk University
Faculty of Informatics
Multilevel Classification in
Master’s thesis
Bogdan Iakym
Brno,autumn 2012
Hereby I declare,that this paper is my original authorial work,which I
have worked out by my own.All sources,references and literature used or
excerpted during elaboration of this work are properly cited and listed in
complete reference to the due source.
Bogdan Iakym
Advisor:Ing.Mgr.Zdeněk Říha,Ph.D.
First of all,I would like to thank my advisor,Ing.Mgr.Zdeněk Říha,Ph.D.,
for his guidance and helpful advices.Many thanks go also to the other col-
leagues fromthe Laboratory of Security and Applied Cryptography.Last but
not least,I am grateful to my family and friends for their love and support.
Thank you all.
Multilevel Security (MLS) systems classify data,based on their confidential-
ity or integrity.One of possible implementation of MLS system is SELinux,
that enforces Bell-LaPudula model (BLP).The goal of this work is to study
and analyze basic components of MLS policy in SELinux.This studying
includes practical experiments related to File System,Inter-Process Com-
munication,Polyinstantiation,Application and Database Support of MLS.
The goal of the practical part is to design,implement and test the config-
uration of MLS policy,applicable for Apache web server.Finally,this work
analyzes the benefits that can be brought by MLS to the security of web
services and the areas in which such systems could be deployed.
SELinux,MLS,security policy,configuration,Bell-LaPadula model,integrity,
confidentiality,security level,access control.
1 Introduction.............................3
1.1 Problematic Area.........................3
1.2 Thesis Outline..........................4
2 SELinux Overview..........................5
2.1 Introduction............................5
2.2 Objects and Subjects.......................7
2.3 Type Enforcement Mechanism.................8
2.3.1 Security Context.....................8
2.3.2 Types and Attributes..................8
2.3.3 Access Vector Rules...................9
2.3.4 Domain Transition....................10
2.3.5 Constraints........................11
2.4 Role Based Access Control....................11
2.4.1 Role Statements.....................12
2.4.2 Users and Roles.....................13
2.4.3 Mapping between Linux and SELinux Users......13
2.5 Audit Logs............................14
2.6 Booleans..............................15
2.7 Object Labeling..........................16
2.8 SELinux Policies.........................17
2.9 Policy Modules..........................18
2.10 The Reference Policy.......................20
2.11 Summary.............................21
3 SELinux Tools for MLS......................23
3.1 Introduction............................23
3.2 Security Levels..........................23
3.2.1 Sensitivities........................24
3.2.2 Categories.........................25
3.2.3 Implementation in the Reference Policy........26
3.2.4 Security Level Translation................27
3.3 mlsconstrain Statements.....................27
3.4 mlsvalidatetrans Statements...................29
3.5 Privilege Management......................30
3.6 Semantics of MLS Policy.....................31
3.7 MLS support...........................34
3.7.1 File System........................35
3.7.2 Inter-Process Communication..............36
3.7.3 Application Support Analysis..............38
3.7.4 Polyinstantiation.....................40
3.7.5 SE-PostgreSQL......................43
3.7.6 Apache SELinux Plus..................44
3.8 Summary.............................46
4 Apache Configuration with MLS Policy............47
4.1 Introduction............................47
4.2 Design of the Configuration...................47
4.3 Deployment of the MLS system.................49
4.3.1 Development Environment...............49
4.3.2 Authentication......................50
4.3.3 Typebounds Approach..................52
4.3.4 Writing Policy Module..................53
4.4 Testing..............................60
4.4.1 Functionality Tests....................60
4.4.2 Performance Analysis..................62
4.5 Summary.............................67
5 Conclusion..............................69
A The CD contents..........................76
1 Introduction
1.1 Problematic Area
We live in the information age,when a huge amount of data are stored in the
computer systems.At the same time,we also know how many attacks aimed
to compromise,manipulate and disrupt these data are currently possible.
It is not something new to claim how important is to be aware of security
mechanisms to protect so expensive information resources.Fundamental se-
curity goals of each system are confidentiality,integrity and availability of
Confidentiality relates to preventing unauthorized access to information
that should be only disclosed to authorized ones.Therefore,a part of con-
fidentiality protection is also authentication that controls whether an entity
is who it claims to be.Confidentiality often refers to protection against ma-
licious software,spam,phishing and different means of social engineering,
where an attacker attempts to obtain confidential information such as user
account passwords,numbers of credit cards or different types of personal
The purpose of integrity protection is to ensure that data were not
changed inappropriately.Violation of integrity includes accidental or delib-
erate attempts to modify,insert or destruct data by unauthorized entities.
Systems that are secure in terms of confidentiality or integrity should
also remain available.In other words,information resources should be avail-
able whenever the authorized users request them.Otherwise,implemented
security mechanisms would be meaningless.
Practical implementation of secure computer systems results in a va-
riety of access controls.Nowadays,operating systems are more and more
focused on improvment of different security means whose goal is to provide
customers with truly qualitive product.One of them is operating system
Linux,which primary comes with Discretionary Access Control(DAC).It is
dominant access control,that we have today.In short,DAC is based on the
concept that individual users can specify who may or may not access the
resource.These restrictions define permissions for particular users,groups
and all others.However,all DAC mechanisms have a fundamental weakness
in that they are not able to recognize critical difference between human users
and computer programs.[1] In other words,a program has the same access
capabilities as the owner of this program,hence,malicious programs,such as
"Trojan horses"could be able to obtain superuser privileges.The mechanism
of Mandatory Access Control(MAC) was called to solve this issue.The key
difference between these approaches is that access control decisions in MAC
are not delegated to individual users,but to special security policies that
define a strict set of permissions for each component of a system.One of the
most common MAC mechanism is multilevel security.
The term"Multilevel Security"(MLS) comes from a military community.
Documents in a military are often labeled according to their sensitivity lev-
els,ranging from unclassified (anyone can see this) to confidential,secret,
top secret,etc.In the 1970s similar concepts started to be considered for
implementation in computer systems.The primary goal was to provide data
with powerfull integrity and confidentiality protection mechanisms.As a re-
sult,such famous MLS models as High-water mark,Bell-LaPudula,Biba and
others appeared.In any MLS model access control verifies whether a par-
ticular subject has the required clearance to access an object with a given
Long time deployment of MLS in computer systems was considered as a
complex,nontrivial task.After implementation of Mandatory Access Con-
trol(MAC) on Linux Operation System,idea of using multilevel security sys-
tems seems to be not just attractive,but really feasible.Security-Enhanced
Linux(SELinux) project is an example of such implementation and currently
integrated into Linux kernel from the version 2.6.It provides an access con-
trol,based on flexible configuration of different types of security policies.
As a result,from the kernel 2.6.12 SELinux supports MLS policy.Probably,
this is the most accessible and opened MLS system that we have today.In
terms of confidentiality and integrity protection,this mechanism presents
powerfull tool,and all its details will be analyzed throughout this work.
1.2 Thesis Outline
The thesis is divided into five chapters.Chapter 1 is this introduction.Main
SElinux concepts and components are presented in Chapter 2.MLS policy
details are described in Chapter 3.In Chapter 4 the design,implementation
and testing of the target configuration is presented.Chapter 5 concludes the
2 SELinux Overview
2.1 Introduction
MLS policy was implemented as a new type of SELinux policy together with
other MAC mechanisms such as Type Enforcement(TE).However,without
understanding basic SELinux concepts it will be difficult to apply and use
effectively MLS tools.So,this introduction presents a brief historical notes
of SELinux evolution and the purpose of its emergence.
If we look at the history of SELinux,we will find that first projects related
to this research started fromthe 1980s.At this time high-assurance operating
system security and microkernel research merged in the project Distribute
Trusted Math(DTMach).[1] Later The U.S.National Security Agency’s re-
search organization took part in this research and developed a number of sub-
sequent microkernel projects.The result of this work was completely new se-
curity architecture Flask,based on flexible type of enforcement mechanism.[2]
However,this technology was only applicable on research microkernels,there-
fore,The NSA started to deploy it on the Linux kernel.First public release
appeared in December 2000 as a collection of kernel patches(for the kernel
2.2.x) and at this time the project was officially named as Security-Enhanced
Linux.After that,wider Linux communities became interested to participate
in this project.The next step in SELinux development was creating a flexible
framework for the Linux kernel that would allow easily to add new security
extentions.This project is known as Linux Security Module,whose main
contributors were the NSA and the SELinux community.[3] This work lead
to inclusion of SELinux in the main Linux kernel,since version 2.6.Devel-
opment of SELinux didn’t stop on this success,because the primary goal
was to make SELinux as much open as possible and,at the same time,to
simplify usage of this quite complex system.The next contributor to the
development of SELinux becomes Red Hat.They took initiative to make
SELinux a part of mainstream distribution and extend it with user-space
tools and services.[1] Fedora Core 2 becomes first distribution with complete
SELinux infrastracture support and tools for its management.Later,Red
Hat released Enterprise Linux 4 as a system with security enhancement,
fully enabled by default.[1].Currently,we may observe the situation when
the majority of modern Linux distributions include SELinux protection and
this only proofs that SELinux becomes more and more popular in operating
system market.
We have mentioned the key points in the evolution of SELinux that
2.SELinux Overview
brings new forms of access control to Linux.But what is the advantage of
this mechanism in comparison to traditional Linux security?To find answer
to this question we should look at the concepts of DAC.For simplicity,we
consider a Linux process and a file.Each process is represented with its real
and effective user and group IDs.Access to these attributes is controlled by
the kernel and set by login process and setuid program.[1] Files are associated
with inodes,containing information about access mode bits and file user and
group IDs.This information includes three bits,defining read,write and
execute operations for file owner,group and all others.These bits are then
used to decide what users and groups may or may not access this file.
Access controls enforced by SELinux present conceptual difference.First
of all,access control attributes are completely determined by special con-
struction,called security context.When the process attempts to access the
file,traditional Linux DAC controls user/group of the process,the file’s ac-
cess mode and user/group IDs and,finally,makes decision,based on these
data.Access control in SELinux doesn’t exclude all these checks,but only
continues this procedure by checking security contexts that can be defined
for both the process and the file.Looking ahead,we would mention that,
actually,the key role in access control decision belongs to the type identifier
which is a part of security context and the whole mechanism,based on types
is called Type Enforcement.The following table[1] is summarizing compari-
son of all we said about access controls in traditional Linux and SELinux.
Table 2.1 Comparison of Access Control in Standard Linux and SELinux[1]
Standard Linux
Adds from SELinux
Process security
Real and effective user
and group IDs
Security context
Object security
Access modes and file’s
user and group IDs
Security context
Basis for access
Process user/group ID
and file’s access modes,
based on file’s user/group
Permission allowed be-
tween process type and
file type
Therefore,we can make a conclusion that SELinux only presents additional
means to build flexible access controls,but doesn’t cancel standard controls,
enforced by DAC.For example,if SELinux allows a process to read a file,
but in DAC this access mode is denied,then a process would not be able
to read that file and vice versa.Using SELinux,we have ability to define
2.SELinux Overview
various objects,permissions,and rules that result in one complex system,
called security policy.These policies can be applied to control operations in
the whole operating systemas well as for individual services.All this chapter
is an overview of basic SELinux components that will help us to understand
the concepts MLS system which is also a part of SELinux project.
2.2 Objects and Subjects
To start with SELinux,we must distinct two key points:Subjects and Ob-
jects.Subject is an entity,initializing an action.As an action,we consider
some kind of performed operation.Typically,subjects perform some opera-
tions on objects,or even on other subjects.Subjects are the actors in com-
puter systems.Initial think is that users would be the subjects,however,
processes are the true actors.[4]
Figure 2.1:High Level SELinux Components[5]
Objects are system resources such as files,sockets,links,database ob-
jects,devices etc.Similar objects are grouped to an object class.In some
cases,processes could appear as objects when other processes perform some
operations on them.Main SElinux components(figure 2.1) can be defined as
follows [5]:
∙ An action is performed on an object and is initiated by a subject(e.g.
a process reads a file).
∙ An Object Manager is aware of the required actions( and
the objects involved(e.g.file) and is able to enforce those actions.
∙ A Security Server makes decisions,based on subject rights and secu-
rity policy rules.
∙ A Security Policy is enforced with the rules,using the SELinux policy
2.SELinux Overview
∙ An Access Vector Cache (AVC) improves system performance by
caching security server decisions.
In short,each action in SELinux is identified by subject,object and the per-
formed operation.Security server checks whether a given request/responce
is in access vector cache,and if not,then consults access rules,defined in
security policy logic.[2] Finally,it makes decision and stores a new entry to
2.3 Type Enforcement Mechanism
Type Enforcement is a core mechanism of SELinux,based on types and
domains.Every object is associated with a type and every process with a
corresponding domain(i.e.type of a process).Access to an object is then
mapped to the problem whether a subject with a given domain may access
an object with a particular type.Types and domains are basic building blocks
of SELinux policy language rules.Having defined these rules,every subject
may only perform operations,explicitly specified in the scope of associated
domain.In Type Enforcement,as in all SELinux MAC mechanisms,the key
concept is the principle of least privileges.Only actions,allowed by the policy
can be performed,all others denied.
2.3.1 Security Context
Every subject and object must be identified in the system.For this purpose,
SELinux uses security contexts,that can be assigned for both entities.It is
represented as variable-length strings,defining the SELinux user,role,type
and an optional security level as follows:
Roles are used to have an access to one or more types.User represents
SELinux user identity and can be associated to one or more roles.An op-
tional field is a level and can be only present if the policy supports MLS or
Multi-Category Security(MCS).In order to check security contexts,SELinux
extends system commands with –Z option.[1] For example,to check security
contexts of files ls -Z command can be used.
2.3.2 Types and Attributes
Having installed SELinux policy,we have types and domains that are al-
ready available.But we may declare own types and give them some set of
2.SELinux Overview
permissions.An attribute is another important construction in SELinux pol-
icy language.It is an efficient way to group types with similar features.[1]
Every type may have one or more attributes and each attribute can be asso-
ciated with one or more types.The difference between types and attributes
is that attributes generally appear in multiple domains,whereas each type
generally appears only in a single domain.[4] By assigning some attribute to
the type,we grant it with all privileges that an attribute has.Before using an
attribute it should be declared first.The following rules declare the attribute
file_type and assign it to the type etc_t:
#attribute file
type is assigned to all types,used for files
attribute file
#type etc
t is assigned to the directory/etc and all files in it
type etc
Another way to associate types with attributes is to use typeattribute
statements.In the next example the type httpd_t is accosiated with the
attribute httpd_server_domains:
#Attribute declaration:
attribute httpd
#Type declaration:
type httpd
#Association with typeattribute statement:
typeattribute httpd
t httpd
The key difference is that in the second case both the type and the attribute
should be previously declared.
2.3.3 Access Vector Rules
The AV rules determine what is allowed for processes to perform.The com-
mon syntax of these rules is the following:[5]
name source
type target
type:class perm
The first parameter rule_name defines a type of AVrule.The next parameter
source_type defines an identifier of a process,attempting to access an object
with an identifier target_type.Object class is defined by parameter class.
The last parameter is the list of permissions that a process will be given.
There exist four types of AV rules:allow,dontaudit,auditallow,and
neverallow[1].The allow rule is the most common statement in the policy
language,which checks whether the operations between the source_type and
target_type are allowed.In the following example process with the domain
httpd_t is allowed to read and create files with the type httpd_sys_content_t:
allow httpd
t httpd
t:file { read create };
2.SELinux Overview
The dontaudit rule stops the auditing of denials.This rule is useful to apply
when it is known that the event always happens,but without real issues.
The auditallow rule only audits the event and the allow rule is still required.
This kind of rules is only useful for auditing purposes.Finally,neverallow
rule is used when an allow rule should not be generated for the operation,
even if it has been previously allowed[1].
2.3.4 Domain Transition
Domain transition is one of the most important issues in SELinux policy
development.This problem appears when we have to consider a way to
securely run the right programs with the right domain.[1] For example,it
would not be desirable for the security of the system if some untrusted
program would have an access to the file/etc/shadow.Therefore,trusted
program should be executed in the corresponding domain (e.g.passwd_t)
and the only ability to access shadow file would result in getting access to
this domain.
Every process inherits the domain of its parent process,unless a domain
transition appears.[6] It means that,if a process operating in the staff_t
domain starts a child process,the child process will operate in the same
Figure 2.2:Domain Transition [6]
If the processes were not able to change their security context,SELinux
access control would not be meaningful.Domain transition is the mechanism
that allows to run child processes in the domain different from the parent’s
domain.[6] Typically,it is performed as a event on executing binary file of the
target program (if a policy allows it).The following rule allows process with
staff_t domain to run in passwd_t domain after executing passwd program,
having passwd_exec_t domain:
2.SELinux Overview
transition staff
t passwd
t:process passwd
After loading this rule,the process will no be able to access file/etc/shadow
directly,however domain transition makes it possible(see figure 2.2).
2.3.5 Constraints
The purpose of Contraints is to provide additional restrictions for AV rules.
Let us assume,the following rule:
allow staff
t passwd
t:process transition;
This simple rule gives a permission to the domain staff_t to transition to the
domain passwd_t.However,it doesn’t check any other conditions.Contraint
is SELinux construction that can be used for it.For example,we can restrict
previous rule by the following statement:
constrain process transition ( r1 == r2 );
Now the transition is only allowed if the source(i.e.process) role(r1) is equal
to the target(i.e object) role(r2).If this condition is not satisfied then tran-
sition is denied for all processes.This example demonstrates how to set
global policy limitations,based on the relations between source and taget
role.Similar constraints can be built,based on other parts of security con-
text such as users and types.[7] This type of statements build the basic logic
of MLS policy[8](mlsconstrain statements,based on security levels) and all
these details will be discussed in the next chapter.
2.4 Role Based Access Control
As it was previously mentioned,a number of domains can be associated with
a single role.At the same time,one domain can be associated with multiple
roles.Role remains invariant before and after domain transition[6].A process
Figure 2.3:Conceptual diagram of RBAC
2.SELinux Overview
may only transition to the domains,defined in the scope of a given role.[6]
RBAC Conceptual diagram is shown on the figure 2.3.From this figure we
can see,that a domain transition is possible fromdomain4 to domain5,but if
the process has the role user_r the transition can not be done.In opposite,
processes,having the role sysadm_r may transition from domain1 to any
other domain from this example.
2.4.1 Role Statements
Roles can be associated with corresponding types.Such association allows
roles and types to coexist in the same security context:
role user
r types { user
t staff
t };
This rule associates role user_r with two types user_t and staff_t.There
also exist three other types of statements related to roles [1]:role allow
rules,role transition rules and role dominance statements.As in
the case of domain transition,it is often necessary to change roles during
program execution.For this purpose role allow rules can be applied:
allow sysadm
r secadm
The above rule allows a process with the role sysadm_r to"switch"to the role
secadm_r.However,it doesn’t allowopaque transition (i.e.fromsecadm_r to
sysadm_r).For that purpose we must write one more role allow rule.This
kind of rule demands explicit participation of the user in the role change
process.[1] But in many cases we need to perform this operation,automati-
cally,without user’s intrusion.Similarly,as we used type_transition rule,
for roles we need role_transition rule.This rule specifies a default role
change after executing some program.Let us consider the following rule:
transition sysadm
r passwd
t secadm
It changes the role sysadm_r of the process to the role secadm_r after exe-
cuting a file with the type passwd_exec_t.This kind of rules are also often
used to change the role of system daemons,where interaction with user is
not required.
The last type of role statements is role dominance statements.We use
them with the purpose to build hierarchical relationships between roles.If a
role dominates some other roles it will automatically inherit all type associ-
ations of that roles [1]:
dominance {role admin
r {role sysadm
r;role secadm
In the above example role admin_r dominates roles sysadm_r and secadm_r,
hence,inherits all type associations of these two roles.
2.SELinux Overview
2.4.2 Users and Roles
SELinux users and Linux users are actually considered as two different iden-
tities.The idea of such approach was to make SELinux user,independent
from its Linux representation.[1] Therefore,changes for Linux user do not
affect SELinux user.As with types and roles,SELinux user must be declared
first and then associated.SELinux user can be associated with one or more
roles,as follows:
user admin
u roles { sysadm
r secadm
r };
This statement declares SELinux user admin_u and associates with two roles
sysadm_r and secadm_r.Configuration of users and rules is very easy,using
semanage program.For example,to check all available associations between
SELinux users and roles one can use the following command:
#semanage user -l
In MLS policy we may also specify MLS level or range.The previous rule
then can transformed to the following:
user admin
u roles { sysadm
r secadm
r } level s0 range s0-s15:c0.c1023;
The same can be done using semanage:
#semanage user -a -R sysadm
r secadm
r -r s0-s15:c0.c1023 -s admin
More details about MLS level and range will be also provided in the next
2.4.3 Mapping between Linux and SELinux Users
Having two different user identities (SELinux and Linux users),the task is
how to associate them.In this case we have one to one mapping.[9] Linux
user can be mapped to exactly one SELinux user.The easiest way to do
it is to use semanage.The following command defines mapping between
SELinux user admin_u and Linux user joe:
#semanage login -a -s admin
u joe
To see all mappings between users the following command can be used:
#semanage login -l
During login session SELinux user can not be changed,in opposite to Linux
user,that might be changed using su or sudo.[9] In system administration
one of the main tasks is to separate ordinary users from privileged.SELinux
MLS policy provides standard set of users with different privileges.Privilege
2.SELinux Overview
of users is defined by the roles,they may access.Typically,the least priv-
ileged user is user_u.This is default user identity assigned to all users,if
other mapping is not explicitly specified in the policy.It could be explained
by the fact,that shell process must always have a valid security context even
for users not defined in the policy.[1] In MLS policy we can also find more
privileged users such as staff_u,sysadm_u,secadm_u,system_u.For exam-
ple,user sysadm_u is used for administrative purposes,such as executing
sudo,system_u is typically assigned to system daemons.
2.5 Audit Logs
Writing and configuration of SELinux policy would be quite difficult without
logs.They help system administrator to fix different problems and analyze
access denials.Two main types of audit events can be classified as follows
∙ SELinux-aware application events - System errors,change of
boolean states,setting of enforcing/permissive mode,relabeling etc.
All these events are logged by the SELinux kernel services and SELinux-
aware applications.
∙ AVC(Access Vector Cache) audit events - Access denials,gen-
erated by AVC system.
Both types of event messages can be stored in two places:/var/log/messages
and/var/log/audit/audit.log.The first file contains messages,generated by
syslog service and AVCmessages,generated before the audit daemon(auditd)
has been loaded.After the audit daemon has been loaded,audit events are
stored in the second file.[5] Typically,AVC message starts with type=AVC
and may look as follows:
#ausearch -m avc -ts 13:20
type=AVC msg=audit(1343992881.544:1053):avc:denied {read}
for pid=1640 comm="httpd"name="index.html"dev=dm-1
ino=264900 scontext=system
content:s1 tclass=file
This message appeared as a violation of MLS policy when process httpd,
having security context system_u:system_r:httpd_t:s0 was attempting to
read a file index.html labeled as system_u:object_r:httpd_sys_content_t:s1.
Using program audit2allow,it is possible to transform AVC messages to
allow rule,as follows:
#ausearch -m avc -ts 13:20 | audit2allow
2.SELinux Overview
#============= httpd
t =============
#!!!!This avc is a constraint violation.You will need to add an attribute to
either the source or target type to make it work.
#Constrain rule:
allow httpd
t httpd
t:file read;
Adding generated rule to the policy,sometimes,solves the problem.But in
the case of global costraint violation this would not help.As it is shown
on our example,the actual reason of access denial was the violation of
MLS constraint("no-read-up"property).In such cases we can use special
attributes,that should be assigned to either the process or object type.
2.6 Booleans
In some cases SELinux can be configured without knowledge of policy writ-
ing.Important features of SELinux policy can be changed without reloading
of the policy.Booleans are SELinux components that allow to do this.They
take value either on or off.To get the list of booleans with the description
the following command can be used:
#semanage boolean -l
SELinux boolean Description
dir ->off Allow ftp to read and write files in the user home
The command above lists booleans,their current value and shows a brief
description of each boolean.However,it doesn’t provide full list of booleans.
Another command"getsebool -a"does this,but without a description.In
this example the first boolean ftp_home_dir is turned off,preventing ftp
from reading and writing to files in home directories.To turn it on(off),
it is enough to use the command"setsebool -P ftp_home_dir on(off)".
Booleans are defined in conditional policies,by special bool statements.These
statements support if/else constructions that specify what rules are valid
under the condition[10]:
bool allow
tty true;
if (allow
tty) {
#Rules if condition is true;
} else {
#Rules if condition is false;
The purpose of booleans is to simplify work of users and system administra-
tors in policy configuration.
2.SELinux Overview
2.7 Object Labeling
For correct work of SELinux policy all its objects must be associated with se-
curity contexts.Every systemobject must have exactly one security context.
The process of assigning security contexts to objects is called object labeling.
It is one of the main issues in systemadministration,policy development and
installation.Every policy installation requires labeling/relabeling of the file
system to assign initial security contexts to objects.After an installation,
security contexts can be changed.In general,all ways of object labeling can
be classified as follows[1]:
∙ Policy statements - The first way how to label objects are state-
ments of SELinux policy language.For example statements,used for
domain transitions may specify how security context can be changed.
∙ Hard-coded defaults - New created object inherits security context
from its creator.For example,when a process creates a new socket,
security context of created socket will be the same as security context
of the process.
∙ Initial SIDs - In SELinux there exist initial security identifiers (SIDs),
used in the situation of missing or invalid label for some object.
∙ Program-requested labeling - SELinux provides different appli-
cation programming interfaces enabling programs to explicitly label
objects.These SELinux-aware applications can enforce a new label(if
the policy allows it).However,there is difference in the time of va-
lidity of the label,assigned by the programs.For example chcon
program provides only temporary changes.It means that after sys-
tem relabeling,security contexts,assigned by this program will not
survive.In opposite,labeling objects with semanage fcontext saves
the security contexts.
Process of labeling strongly depends on the fact to what object class a given
object belongs.For the most object classes SELinux implements the con-
cept that created object inherits security context of the creating process,
containing object or combination[1].For example,newly created file obtains
a type from the directory containing it,hard-coded role (object_r) and the
SELinux user of the creating process.Processes obtain their contexts in
two basic ways:inherit from parent process or change it using domain/role
2.SELinux Overview
2.8 SELinux Policies
SELinux is configured via policies.Policy is a set of rules that cotrol an access
to objects of the system.All policies can be classified using the following
∙ Based on the source code:Example,Reference or Custom policy
∙ Further descriptions of the source code can also lead to sub-classification:
Monolithic,Base Module or Loadable Module
∙ Based on functionality:targeted,mls,strict or minimum
∙ Based on language statements:Modular,Optional or Conditional
∙ Based on policy version (e.g.18,22,24)
The first policy developed for SELinux was called the Example policy.[1]
The source of this policy was used to build monolithic policy and didn’t
support modules.Later this policy was replaced by the Reference policy,
which is currently the standard SELinux policy source.Customized versions
of the Example or the Reference policy can be classified as the Custom
Using the source of Reference policy,we may install policies with different
security goals.For example,mimimum policy confines only a few specific
daemons.Targeted policy confines all processes,except those,having un-
confined_t domain.This domain is also assigned to the processes started by
the init scripts that do not have defined policy rules.[12] Strict policy is sim-
ilar to the targeted,but all processes are confined,without exceptions.MLS
policy is further development of strict policy,but it enforces Bell-LaPudula
model,using security levels.[12]
The way of compiling the policy leads to further classification.The policy
that is compiled from one source file is called monolithic policy.These
policies can not be managed on modular basis.The Example policy is an
example of monolithic policy.In opposite,the Reference policy supports
loading policy modules which is a great advantage for policy writers.After
installation Reference policy we have policy sources,its base module and
a number of modules that control different services.Base module or base
policy define rules for the core components of the system and should be
always present.[11] Each concrete service can be confined by its module that
can be optionally loaded or unloaded.Compiled base module (and other
modules) has also a corresponding version.
2.SELinux Overview
Based on language statements,we can further classify policies.For exam-
ple,policies that enable defining booleans could be classified as conditional
policies.Policies that allow to define rules that can be enabled in the binary
policy only after some condition was satisfied can be also classified as op-
tional policies.[11]
Every policy works in two modes:permissive and enforcing(or can
be fully disabled).In permissive mode every operation is allowed.Denied
operations are immediately notified in logs.This mode is often used in the
policy development process (so called “debugging” mode).Enforcing mode
enables SELinux policy,denying access and logging actions.
For studing MLS policy,we may install it together with the Reference
policy.If we don’t need policy sources(that is without.te files),we may install
only base policy module(and modules for concrete services),with necessary
configuration files.The last can be done using the following command:
#yum install selinux-policy-mls
After an installation has been completed,it is necessary to turn the policy
on in the configuration file/etc/selinux/config,using an option SELINUX-
TYPE=mls.After that,relabeling of the systemmust be done.The following
command will relabel the system with new labels after reboot:
2.9 Policy Modules
Policy modules are currently basic components of the Reference policy.The
majority of type enforcement rules are implemented within modules.They
control behaviour of different applications,services,devices and many other
system elements.They are transparent to other modules through interfaces
that allow an access to the module rules.[13]
Let us review the process of policy module creating.To create a mod-
ule,we must define three files:<module_name>.te,<module_name>.fc and
<module_name>.if.In the first file we define name of the module,its ver-
sion,declarations and type enforcement rules.The common structure of the
.te file may look as the following:
<required types,attributes,object classes...>
2.SELinux Overview
<policy rules>
Using gen_require macro we can specify the necessary selinux components,
defined in other modules.In the file contexts file (.fc) we can specify ob-
jects and the default labels they should have.For example,the following line
defines the security context system_u:object_r:myapp_exec_t:s0 for the bi-
nary file myapp:
/usr/bin/myapp - gen
The interface file (.if) defines macros,that can be used by other modules.For
this purpose SELinux uses m4 macro language.It simplifies future reusage of
the defined rules.More information about m4 is available in the manual page
man m4 and corresponding documentation[14].Let us assume the policy
module for an application,running in myapp_t domain,having entrypoint
domain myapp_exec_t.The following example is taken from[13] and demon-
strates how to create an interface that allows other domains to do a domain
transition to myapp_t,by executing a program labeled as myapp_exec_t:
##Execute a domain transition to run myapp.
##<param name="domain">
##Domain allowed to transition.
type myapp
This interface defines new macro myapp_domtrans where $1 represents the
parameter passed to this macro.It calls domtrans_pattern macro,that takes
$1 as the first parameter and allows it to transition to the specified domain[13]
(in our case myapp_t with the entrypoint myapp_exec_t).
The final step in policy module development is compiling the module and
loading it to the kernel.The first can be done by Makefile(typically,available
#make -f/usr/share/selinux/devel/Makefile
The command above checks the module on syntax errors and if succeded,the
policy package file <module_name>.pp will be created.To load the module
2.SELinux Overview
into the kernel we can use the following command (must be executed with
superuser privileges):
#semodule -i <module
To ensure that the policy module is in the kernel we may check the list of
loaded modules:
#semodule -l | grep <module
2.10 The Reference Policy
As it was mentioned The Reference policy is currently the basis for building
different SELinux policies.The original version can be obtained from the
official repository of Tresys Technology,available at http://oss.tresys.
com/projects/refpolicy/.To understand the internal structure of the
Refence policy it can be represented as the policy source tree(figure 2.4.)[5]
As we may see from the figure,it has a quite complex architecture.Let us
Figure 2.4:Reference policy source tree[5]
review the most important components.All this information can be found
in the Reference policy.[15]
2.SELinux Overview
Makefile contains general rules for buiding the policy.We can build
monolithic policy or loadable module policy and corresponding rules for each
option are defined in Rules.monolithic and Rules.modular files respec-
tively.Basic configuration options such as policy type(e.g.targeted,mls) and
distribution details can be defined in the build.conf file.In the config direc-
tory we can find application configuration files for all policy types(including
MLS policy),used by SELinux-aware programs.The necessary documen-
tation is provided in the doc section.Policy support scripts used in the
build process are located in the support directory.The majority of con-
figuration files are in the policy directory.Here we can find declarations
of security classes(policy/flask/security_classes),access vectors (pol-
icy/flask/access_vectors),booleans and their default values (policy/-
booleans.conf),standard users(policy/users) and many others.It makes
no sense to describe all these files as we may always refer to the necessary
sources of the Reference policy.[15] Let us better focus on the important
configuration files for the MLS policy.
Security levels are defined in the file/policy/mls.Besides constrain
statements,MLS policy uses special constraints,based on security levels
(mlsconstrain statements)[8] which are also defined in this file.In the di-
rectory/policy/support/we can find support macros,used to build the
Reference policy source modules.For example,file mls_mcs_macros.spt is
responsible for MLS (and Multi-Category Security) support.Policy source
modules can be found in the/policy/modules/directory.Modules are
grouped according to the services they confine.For example,kernel group
contains policy modules,confining kernel-related services.In this group there
is also mls module,which defines attributes used in MLS policy (/policy
/modules/kernel/mls.te) and the corresponding interfaces (/policy/mod-
ules/kernel/mls.if).MLS attributes are often used for privilege manage-
ment and they will be also discussed in the next chapter.
2.11 Summary
In this chapter we studied the basic concepts of SELinux with focus on MLS.
Our studying started from describing two basic elements of access control:
subjects and objects.Objects represent all available resources in the system,
and their variety requires a proper classification into object classes.SELinux
implements access control by explicit specifying rules,which create a policy.
The majority of each policy rules is created from type enforcement rules.
Every object is associated with a security context,represented with user,
role,type and optionally security level.One of the main issues that appear
2.SELinux Overview
in policy development is transition problem that relates to domain types
and roles.SELinux and Linux users are two different entities and do not
affect each other.Another important task is to separate privileged users from
unprivileged.For this purpose SELinux provides standard list of users,where
the least priveleged is assigned by default(e.g.user_u).Assigning security
context to objects/subjects is called labeling and it is another important
issue that should be considered in whatever policy development.Then,we
described currently available types of policies and properly classify them.For
work with MLS,we may install base MLS policy,but for deeper analysis we
need Reference policy that includes all necessary policy sources.Every policy
works in permissive and enforcing mode,or can be completely disabled.
For debugging purposes permissive mode is more suitable,while enforcing
enables denying access.From our point of view security of MLS as wel as
other SElinux mechanisms highly depends on the security of Linux kernel
and potential kernel breach can be considered as one of the factors that can
make MLS vulnerable.
3 SELinux Tools for MLS
3.1 Introduction
Multilevel Security in SELinux represents a new form of Mandatory Access
Control.It is bulit upon Type Enforcement,but exdends it with newfeatures.
The Bell–LaPadula model (BLP) was chosen as the base.This model focuses
on data confidentiality[16],in contrast to Biba model which is oriented on the
intergrity protection[17].In terms of the BLP model all processes have their
security level,allowing them to access objects with the same security level
(read and write).Moreover,a process may read objects with lower security
level and write to objects with higher security level,but not the reverse[18](as
shown on the figure 3.1).These concepts are also known as"no-read-up"and
"no-write-down"rules.In this chapter we study MLS system in SELinux
Figure 3.1:Bell–LaPadula Model
which is implemented as a new policy type.
3.2 Security Levels
As we remember,the fourth field of a security context is an optional com-
ponent [:level].Security level or simply level consists of sensitivities and
1.The figure was created by my own,however the image of"Process"and the icons
to illustrate levels"Top Secret","Secret","Confidential"and"Unclassified"provided by
"Google Images"service
3.SELinux Tools for MLS
categories.Sensitivities can be also understood as classifications(e.g.Con-
fidential,Secret,Top Secret,etc.) and categories as compartments(e.g.Fi-
nance,Marketing,Personnel,etc).Currently,the Reference SELinux policy
defines 16 sensitivities(s0,...,s15) and 1024 categories(c0,...,c1023)(these val-
ues are defined in the file build.conf of the Reference policy[15]).In the MLS
system,extended security context is represented in the following format:
Security level consists of sensitivity and zero or more categories,but it can
be also represented as a range.Low security level consists of low sensitivity
and,optionaly,a set of categories.It is applied for subjects and objects
and is also known as the Current or Effective security level.The lowest
security level in the system is defined as SystemLow and doesn’t contain
any categories(that is s0).Category set can be defined in two ways.Using
comma we may list each category as:c0,c1,c2,c3.The same could be done,
using inclusive operator"dot":c0.c3.High security level consists of high
sensitivity and optional set of categories.It is also known as the Clearance.
The highest level SystemHigh consists of the highest sensitivity(e.g.s15)
and all available categories(e.g.c0.c1023).Security levels are defined using
special level statements,as follows:
level s2:c0.c5;
These statements set the association between sensitivities and categories.
They can not be used in policy module,only in Base and Monolithic policies.[5]
3.2.1 Sensitivities
Sensitivities are hierarchically ordered components of a security level.[1] To
define sensitivities,we may use special sensitivity statements as in the
example bellow:
sensitivity s0;
sensitivity s1 alias Confidential;
We defined two sensitivities s0 and s1 and for the last we also defined the alias
name Confidential.Defining an alias is optional.These statements can be
defined in Monolithic and Base policy,but not in Module policy.[5] To create
hierarchical relations between sensitivities the dominance statements are
#The MLS Reference Policy dominance statement defines s0 as the
#lowest and s15 as the highest sensitivity level:
dominance { s0 s1 s2 s3 s4 s5 s6 s7 s8 s9 s10 s11 s12 s13 s14 s15 }
3.SELinux Tools for MLS
On the above example we ordered 16 sensitivities.In braces we list them,
where left most value is the lowest and right most is the highest.
3.2.2 Categories
In contrast to sensitivities,we can not compare categories as they are not
hierarchically related.[1] Their values are defined,using the category state-
ments as follows:
category c0;
category c1 alias Finance;
As in the case with sensitivities,we may define category with or without an
alias.These statements are also valid in the Monolithic and the Base policy,
however not in the Module policy.[5] Categories can be used not only in the
MLS policy.For example,in the targeted policy security level is represented
with one sensitivity s0 and zero or more categories.The mechanismof access
control,that uses categories is also known as Multi-Category Security(MCS).
James Morris gave a nice discriprion of MCS[19]:"In a nutshell,MCS is an
enhancement to SELinux which allows users to label files with categories.
These categories are used to further constrain DAC and TE logic."
Let us look at simple examples of access control,based on MCS.At first,
let us define a user with the permission to access three categories c0,c1 and
[root@localhost]#chcat -l - +c0,+c1,+c2 admin
The command above defines this permission for Linux user admin.To check
the categories accessible for this user the following command can be used:
[root@localhost]#chcat -L -l admin
Then,let us create an arbitrary file and label it with the same set of cate-
[root@localhost]#echo ’File labeled with the categories’ >/tmp/file
[root@localhost]#chcat -- +c0,+c1,+c2 file
admin’s shell:
[admin@localhost]$ cat/tmp/file
File labeled with the categories
Now user admin may successfully read the file.But removing at least one
category from the user’s security level or adding at least one new category
to the file’s level will deny an access.Let us add a new category to the file
and test the results:
3.SELinux Tools for MLS
[root@localhost ]#chcat -- +c3/tmp/file
admin’s shell:
[admin@localhost tmp]$ cat/tmp/file
cat:/tmp/file:Permission Denied
As we may see,at this moment permission is denied.It could be explained
by the fact,that a set of categories of an object(in our case it is a file) must
be completely subsumed by a set of categories that a user(user’s process)
may access.[6] In our case it doesn’t hold as the user admin can not access
the category c3.
3.2.3 Implementation in the Reference Policy
Sensitivities and categories as well as security levels can be easily defined
using corresponding policy language statements.However,manual definition
of these components is not an effective way.For example,if we plan to use
1024 categories,it would not be desirable to call category statements 1024
times.To automatize this procedure,the Reference policy uses advantages
of m4 macro language.For example,the following piece of code is taken from
the file mls_mcs_macros.spt[15] and demonstrates how to define categories:
#File categories.m4
category c$1;
cats(incr($1),$2)’)dnl ’)
At first,macro decl_cats is declared,which takes two numeric arguments $1,
$2 and generates category statements for each category starting fromc$1 and
ending in c$2.For this purpose,it uses recursive macro ifelse that compares
both arguments in each iteration and increments $1 until they match.Details
of m4 macro language can be found in the available documentation.[14] After
that,we defined macro get_cats which uses decl_cats to define categories
from c0 to c(N-1).So,all we need to define 1024 categories is to apply
macro get_cats(1024),that will generate categories from c0 to c1023:
#m4 categories.m4
category c0;
category c1;
category c1023;
Macro get_cats is used in policy/mls file[8] of the Reference policy to generate
categories for MLS(and MCS).Similar approach is used to define sensitivities
and security levels.For example,security levels can be defined using the
following m4 construction:
3.SELinux Tools for MLS
level s$1:c0.c$3;
levels(incr($1),$2,$3)’)dnl ’)
Macro gen_levels then can be used to declare security levels with sensitivities
from s0 to s(N-1) and categories from c0 to c(M-1).[8]
3.2.4 Security Level Translation
Sensitivities and categories can be given human readable names.The first
way is using aliases in sensitivity and category statements.The other way
is using mcstrans service.The configuration file used by this service is
typically located in/etc/selinux/mls/setrans.conf.To list configured trans-
lations,the following command can be used:
#chcat -L
s0 SystemLow
s15:c0.c1023 SystemHigh
s0-s15:c0.c1023 SystemLow-SystemHigh
s1 Unclassified
s2 Secret
s2:c0 A
s2:c1 B
s2:c0,c1-s15:c0.c1023 Secret:AB-SystemHigh
This command outputs all translations,defined in the file setrans.conf.To
set new translations it is enough to modify this file,as follows:
#echo ’s3=TopSecret’ »/etc/selinux/mls/setrans.conf
#service mcstrans restart
The first cammand adds new line to the file setrans.conf,defining the name
TopSecret for the sensitivity s3.To update translation list it is necessary to
restart mcstrans.In similar way we may define translations for categories as
well as for the whole security level.
3.3 mlsconstrain Statements
The basic logic of the MLS policy is defined by special mlsconstrain state-
ments.They allow to restrict permissions for particular object classes,based
on security levels of a source process and a target object.Security level is rep-
resented by its low(l1 for the source and l2 for the target) and high value(h1
for the source and h2 for the target).Formal syntax of these statements is
the following[5]:
3.SELinux Tools for MLS
mlsconstrain class
set perm
set expression;
Parameter class_set represents one or more object classes(e.g.{file dir lnk_file}).
perm_set defines permission set (e.g.{read gettattr execute}).The main part
of the statements is boolean expression,that can be determined as follows[5]:
not expression
expression and expression
expression or expression
u1 op u2
r1 oprl r2
t1 op t2
l1 oprl l2
l1 oprl h2
h1 oprl l2
h1 oprl h2
l1 oprl h1
l2 oprl h2
u1 op names
u2 op names
r1 op names
r2 op names
t1 op names
t2 op names
Source type,role,user,low level,high level
Target type,role,user,low level,high level
== |!=
== |!= | eq | dom | domby | incomp
Set member of or equivalent
Set not member of or not equivalent
dominated by
name | { name_list }
{ name_list } | name
In general,formal syntax is similar to SELinux constrain statements.[7]
Operators,defined by oprl can be also used to compare roles.The following
mlsconstrain statement implements a simple"no-read-up"rule:
mlsconstrain file {read getattr execute}
( (l1 dom l2) or
3.SELinux Tools for MLS
(t1 == mlsfilereadup) );
It is applied for the file object class.Permission set is represented by read(file
reading),getattr(getting file’s attributes) and execute(file execution).The
first part of the boolean expression states that low level of the source process
must dominate low level of the target object.In other words processes may
read files only on its Current or lower security levels.In the second part of
expression we defined an exception fromthe rule (that is processes,having an
access to the attribute mlsfilereadup may violate"no-read-up"rule,whatever
security level they have).In similar way,we may define"no-write-down"rules,
but instead of dom operator we should use domby (that is the source low
level must be dominated by the target low level) and list the corresponding
permissions and objects.
As it was mentioned,mlsconstrain rules are implemented in the main
MLS policy source file[8] (/policy/mls) of the Reference policy.This file con-
tains limitations related to different object classes and permissions.To start
working with MLS policy,we recommend to get acquainted with this file,as
it plays a key role in the behaviour of the MLS system.
3.4 mlsvalidatetrans Statements
This type of statements is only applied for file-related object classes to control
the ability to upgrade/downgrade security level.The formal syntax is similar
to mlsconstrain statements,but there is a bit difference[5]:
mlsvalidatetrans class
set expression;
One or more file type object classes
A boolean expression of the constraint
Old user,role,type,low level,high level
New user,role,type,low level,high level
Process user,role,type,low level,high level
Let us look at the following example to understand how these statements
mlsvalidatetrans file
(( l1 eq l2 ) or
(( t3 == mlsfileupgrade ) and ( l1 domby l2 )))
The first part of the boolean expression (l1 eq l2) states that file’s security
level can be changed if its current(old) low level is equal to the new file’s low
security level.The second part or (( t3 == mlsfileupgrade ) and ( l1 domby l2
3.SELinux Tools for MLS
)) claims:or the process type must be privileged with the mlsfileupgrade
attribute and file’s current lowsecurity level must be dominated by newfile’s
low security level.It was an example of file’s upgrading.In similar way we
can also define an expression for file downgrading.In this case it is enough to
change only the second part of the expression:or (( t3 == mlsfiledowngrade
) and ( l1 dom l2 ))
The mlsvalidatetrans statements are equivalent of the SELinux validate-
trans statements[7],with additional conditions,based on security levels.
These statements are also defined in the/policy/mls file[8] of the Reference
3.5 Privilege Management
MLS policy provides a flexible mechanism of privilege management,based
on special type attributes.These attributes can be used to obtain access
privileges for different objects.For example,the attribute mlsfileread is al-
lowed to read files at all levels.To obtain privileges of this attribute it is
enough to define the following rule:
typeattribute mytype
t mlsfileread;
The same could be done by using the macro:
All attribute names and interface calls start with"mls".[15] The following
table presents some important MLS attributes with their descriptions:
Grant MLS read access to files not dominated by
the process Effective SL
Grant MLS read access to files dominated by the
process Clearance SL
Grant MLS write access to files not equal to the
Effective SL
Grant MLS read access to packets not dominated
by the process Effective SL
Grant MLS write access to IPC objects not equal
to the process Effective SL
Grant MLS read access to processes not dominated
by the process Effective SL
Grant MLS read/write access to objects which in-
ternally arbitrate MLS
3.SELinux Tools for MLS
The mechanism of using attibutes is an ellegant approach,because it al-
lows us to implement different MLS information flows without global policy
overrides[20].All limitations,defined by mlsconstrain and mlsvalidatetrans
statements specify these attributes and the way,they can be used,to bypass
those limits.Full list of available attributes and their descriptions can be
also obtained from the Reference policy.[15]
3.6 Semantics of MLS Policy
In this part of the thesis we discuss the analytical model,presented in the pa-
per [21].It helps to understand the meaning of MLS statements,we described
in the previous sections.First of all,the authors present four basic operators
to handle MLS statements:name,classes,modes and expr.The first opera-
tor name takes some statement and returns its name.Operator classes gets
objects classes of a given statement.The last two operators modes and expr
return a set of permissions and boolean expression of a statement respec-
tively.Example of applying these operators for mlsconstrain statement:
(      {  }( 1  2)) =   
 (      {  }( 1  2)) =  
(      {  }( 1  2)) = {  }
(      {  }( 1  2)) = ( 1  2)
Operators classes and modes can be also applied to the whole policy,not
only statements.Presented model also includes operators that return each
component of a security context:getu(returns user),getr(role),gett(type),
getl(low level),geth(high level),getsens(sensitivities),getcat(categories).
For comparison of security levels,it is important to distinguish properly
sensitivities,categories,and the whole security level.As it is known,sen-
sitivities are hierarchical components,therefore,the following definition of
total order can be applied for dominance statements:[21]

) ≡    ,⊑



−    ℎ  (.. ), = 1,...,
However,in the case when security level consists of categories,it is not
so straightforward.Categories can not be ordered,therefore,for level state-
3.SELinux Tools for MLS
ments we may define only partial order:[21]




) ≡     ,⊑
∈ ({



∈ ({


}) ..
The following definition gives formal description of the MLS ranges:[21]
 ( ) = {( 1, 2)|( ( 1) ⊑  ( 2))∧( ( 1) ⊆  ( 2))}
Further step in bulding this analytical model is determining of the meaning
for each operator used to compare security levels:[21]
 (==, 1, 2) = ( 1 = 2)
 (!=, 1, 2) = ( 1 ̸= 2)
 ( , 1, 2) = ( ( 2) ⊑  ( 1)) ∧( ( 2) ⊆  ( 1))
 ( , 1, 2) = ( ( 1) ⊑  ( 2)) ∧( ( 1) ⊆  ( 2))
 (  , 1, 2) = ¬( ( , 1, 2)) ∧ ¬( ( , 1, 2))
All these definitions were presented in order to support the main defini-
tion of this model.It contains two operators 

,that allow to
detect and evaluate mlsconstrain and mlsvalidatetrans statements respec-
tively.Let us focus on the first operator,and show a concrete example of its
The value of 

(,,,) is TRUE when all the constrains relevant
to the 4-tuple are satisfied.If there are no constraints for a given 4-tuple,

(,,,) is vacuously TRUE.Formally,it can be defined as follows:[21]

(,,,) = ({ |  ∈  , ( ) =    ,
 ∈  ( ), ∈ ( ),‖( )‖
=  } = ∅)
In the above definition stmt represents statement,s - source subject,o -
target object,c - object class,p - permission.A boolean expression of the
statement has the following semantical meaning:[21]
) = ¬(‖‖


= ‖

∧ ‖



= ‖

∨ ‖

‖1 == 2‖
= (() = ())
‖1!= 2‖
= (() ̸= ())
‖1  2‖
=  (,(),())
‖1 == 2‖
= (() = ())
3.SELinux Tools for MLS
‖1!= 2‖
= (() ̸= ())
‖ 1  2‖
=  (, (), ())
‖ 1  ℎ2‖
=  (, (),ℎ())
‖ℎ1  2‖
=  (,ℎ(), ())
‖ℎ1  ℎ2‖
=  (,ℎ(),ℎ())
‖ 1  ℎ1‖
=  (, (),ℎ())
‖ 2  ℎ2‖
=  (, (),ℎ())
Example.A user,having security context staff_u:staff_r:staff_t:s1-s3:c0.c10
attempts to performthree operations search(directory search),add_name(add
new file to the directory),remove_name(remove file from the directory)
in the home directory,labeled as system_u:object_r:user_home_t:s2:c0.c5.
Assume that corresponding allow rule is implemented in the policy(that is
TE allows to perform these operations on the given object).MLS policy
controls the operations by the following mlsconstrain rules:
     ℎ (( 1  2)  (ℎ1  2))
    { _   _ }(( 1  2)  ((ℎ1  2)
 ( 1   2)))
The task is to evaluate 

and find out whether the operations for the
user are allowed with the specified mlsconstrain statements.
Step1.At first,let us define all necessary parameters:
s = staff_u:staff_r:staff_t:s1-s3:c0.c10,
o = staff_u:staff_r:user_home_t:s2:c0.c5
c = dir,getl(s) = s1,getl(o) = geth(o) = s2:c0.c5,geth(s)=s3:c0.c10,
getsens(l1) = s1,getsens(h1)= s3,getcat(l1) = ∅,getcat(h1)=c0.c10
getsens(l2) = getsens(h2) = s2,getcat(l2) = getcat(h2) = c0.c5
Step2.Evaluation of the first mlsconstrain statement:
  =      ℎ (( 1  2)  (ℎ1  2)),
( ) =    , ( ) = , ( ) =  ℎ,
‖( )‖
= (( 1  2)  (ℎ1  2))
( 1  2) =  ( , (), ()) =  ( ,1,2:0.5)
= ( (2:0.5) ⊑  (1)) ∧( (2:0.5) ⊆  (1))
= (2 ⊑ 1) ∧({0,...,5} ⊆ ∅) =   ∧  =  
(ℎ1 2) =  ( ,ℎ(), ()) =  ( ,3:0.10,2:0.5)
= (( (2:0.5) ⊑  (3:0.10)) ∧( (2:0.5)
⊆  (3:0.10)) = (2 ⊑ 3) ∧({0,...,5} ⊆ {0,...,10})
3.SELinux Tools for MLS
=  ∧ = 
‖( )‖
= ( 1  2) ∨(ℎ1  2) =   ∨ = 

(,,,) = , = ( ) =  ℎ
Step3.Evaluation of the the second mlsconstrain statement:
  =     { _   _ } ( 1  2)
 ((ℎ1  2)  ( 1   2))
( ) =    , ( ) = ,
( ) = { _   _ },
‖( )‖
= ( 1  2)  ((ℎ1  2)  ( 1   2))
( 1  2) =  (==, (), ()) =  (==,1,2:0.5)
= (1 = 2:0.5) =  
( 1   2) =  ( , (), ()) =  ( ,1,2:0.5)
= ( (1) ⊑  (2:0.5)) ∧(( (1) ⊆  (2:0.5))
= (1 ⊑ 2) ∧(∅ ⊆ {0,...,5}) =  ∧ = 
 = (ℎ1  2)  ( 1   2) = (ℎ1  2) ∧( 1   2)
=  ∧ = 
‖( )‖
= ( 1  2)   = ( 1  2) ∨
=   ∨ = 

(,,,) = , ∈ ( ) = { _   _ }

(,,,) returns TRUE for both mlsconstrain statements,therefore,
the user is not constrained to perform the operations.Similar approach can
be used to define 

,but we omit this,because the purpose of this part
of the thesis was to convey the main idea of using MLS policy semantics,
published in the discussed paper.
Presented analytical model is an attempt of the authors to emphasize the
importance of understanding the semantics of the SELinux MLS policy.Its
main applications are:determining whether the policy constrain all defined
object classes and permissions,checking whether information-flow goals are
properly implemented,policy compliance testing in distributed systems.
3.7 MLS support
This part of the work will be more practical in order to understand the
behaviour of MLS system in SELinux.This studing includes experiments
with MLS policy related to OS and application level support.
3.SELinux Tools for MLS
3.7.1 File System
In the first part of the practical studying we explore file system under MLS
policy.According to the SELinux Reference policy[8] each file is given a
single level.To study the behaviour of file system in MLS environment we
may find the appropriate mlsconstrain rules for the file-related classes in the
Reference policy.The first such rule controls creation and ralabeling of files:
#make sure these file classes are"single"level
mlsconstrain{ file lnk
file fifo
file } { create relabelto }
( l2 eq h2 );
Obviously,this rule means that file’s(including link and fifo files) low level l2
must be equal to file’s high level h2.Therefore,file can not be labeled with
a level range.Considering reading operations,performed on the file-related
objects,one can find the following rule:[8]
#the file"read"ops (note the check is dominance of the low level)
mlsconstrain{ dir file lnk
file chr
file blk
file sock
file fifo
file }
{ read getattr execute }
(( l1 dom l2 ) or (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsfileread ) or ( t2 == mlstrustedobject ));
We may interprete the above rule as follows:every subject may read files
(and other file-related objects,such as link files,sockets,fifo files) only if
subject’s low level dominates object’s level or subject’s type is privileged
with the attribute mlsfilereadtoclr and it’s high level dominates low level of
the object.At the same time,no reading restrictions are applied if the sub-
ject’s domain is privileged with the attribute mlsfileread.The last condition
cancels all restrictions if the rules of mlstrustedobject attribute applied for
the object’s type.The same mlsconstrain statement could be found in the
case of directory listing("mlsconstrain dir search"and condition remains the
same as in the previous statement).[8] To test directory listing,we created
two users:user1 and user2,with the levels s1 and s2 respectively (each has
a single level,not a range).And we also created two files:file_s1 of level s1
and file_s2 of level s2.The result of command ls is given below:
user2’s login session:
[user2@localhost somedir]$ ls -l
-rwxrwxrwx.1 user1 user1 0 Mar 23 10:47 file
-rwxrwxrwx.1 user2 user2 0 Mar 23 10:47 file
user1’s login session:
[user1@localhost somedir]$ ls -l
ls:cannot access file file
s2:Permission denied
total 0
-rwxrwxrwx.1 user1 user1 0 Mar 23 10:47 file
3.SELinux Tools for MLS
As it was expected,reading operation getattr,in the case of user1,is violating
"no-read-up"property for the file_s2.Another interesting detail is that file
name still remains visible and could be,therefore,treated as possible leak
of data from the upper level.[22] Security policy doesn’t allow to create
hard links to the file with higher level,but doesn’t prevent it in the case of
symbolic links.However,creating symbolic link is meaningless as MLS policy
doesn’t pay attention to the link itself but to the original file.For example,
user1,attempting to create a symbolic link for inaccessible file file_s2,would
not have any chance to obtain data fromthis file.This example is also tested
and shown bellow:
creating hard link fails:
[user1@localhost somedir]$ ln/somedir/file
ln:accessing ’/somedir/file
s2’:Permission denied
creating symbolic succeeds,but data in the original file is still secured:
[user1@localhost somedir]$ ln -s/somedir/file
[user1@localhost somedir]$ cat/home/user1/file
symlink:Permission denied
For testing purposes we allow all the neccessary permissions,to be passed
through DAC and TE.It allows us ensure that access control is enforced
only by MLS constraints.
According to BLP model writing operations to upper levels should be
allowed.However,practical implementation of MLS policy shows that writ-
ing operations often intersect with reading operations.For example,before
writing to a file a policy must check its attributes first,which is,of course,
considered as reading operation.This problem is known as usability limita-
tion when many system commands can not be normally executed without
restrictions.[22] Apossible solution could be using MLS attributes or internal
modifications in the MLS policy.
3.7.2 Inter-Process Communication
Inter-process Communication (IPC) is another important aspect of studying
MLS policy.When a process is called it gets security level of its launcher.[22]
Let us consider the same users user1(level s1) and user2(level s2) when both
execute"top"program from their terminals to observe processes,running in
the system:
top,launched by user1:
4707 user1 20 0 2724 1084 848 R 0.3 0.1 0:00:50 top
4672 user1 20 0 5272 1656 1412 S 0.0 0.2 0:00:03 bash
top,launched by user2:
3.SELinux Tools for MLS
4637 user2 20 0 5272 1652 1412 S 0.0 0.2 0:00:03 bash
4672 user1 20 0 5272 1656 1412 S 0.0 0.2 0:00:03 bash
4707 user1 20 0 2724 1084 848 S 0.3 0.1 0:00:53 top
4710 user2 20 0 2720 1084 848 R 0.0 0.1 0:00:55 top
As we may notice,processes,executed by user2 are not observable for user1,
because user1’s level is bellow the level of processes,executed by user2.So,
process visibilty is controlled correctly in relation to"no-read-up"property.
According"to no-write-down property",processes should be allowed to
send signals to the upper-level processes.But in practice we face again with
interlacing problem[22].For example,user1 can not send signals to the pro-
cesses,runned by user2.It could be explained by the fact that user1 is
supposed not to know user2 has processing running.[22]
To test this behaviour,we focused on the message queue.For this pur-
pose,we created two simple applications:message_send for sending messages
to a queue and message_receive to fetch the message.First application has
two parameters:key(identifier of the queue) and the message itself.Program
message_receive allows to retrieve corresponding message from the queue
with the specified key.Both users launched message_send with different
messages and keys.Then we studied the following scenario:each user at-
tempts to list the message queues and then retrieve the message each from
its opponent(we assume that each user is aware of opponent’s message queue
key).The experiment showed that user1 was able to observe only queues with
level s1 and any attempt to fetch messages,created by user2 failed.In op-
posite,user2 observed the list of queues,created by user1,however,failed
to fetch user1’s message.The results of this experiment are given bellow:
user1’s login session:user2’s login session:
send 111 Hello./message
send 222 Help
msgget:Calling msgget(0x6f,01777) msgget:Calling msgget(0xde,01777)
Queue id:196608 Queue id:229377
Message Hello added to queue...Message Help added to queue...
ipcs -q ipcs -q
---- Message Queues ----- ---- Message Queues -----
key msqid owner perms used-bytes messages key msqid owner perms used-bytes messages
0x0000006f 196608 user1 777 6 1 0x0000006f 196608 user1 777 6 1
0x000000de 229377 user2 777 5 1
receive 222./message
receive 111
msgget:Permission denied msgget:Permission denied
receive 111./message
receive 222
msgget:Calling msgget(0x6f,01777) msgget:Calling msgget(0xde,01777)
Message Hello successfully fetched Message Help successfully fetched
3.SELinux Tools for MLS
Inability of user2 to retrieve message from user1 could be explained by the
fact,that system call msgget requires unix_write permission,which is obvi-
ously considered as writing operation.We found this,anylyzing AVC logs:
type=AVC msg=audit(1345797378.896:1608):avc:denied { unix
write } for pid=2717
receive"key=111 scontext=staff
t:s1 tclass=msgq
So,in this case user2 faced with"write down"operation.This experiment is
a nice example,showing how reading and writing operations may interlace,
and that it is often difficult to find border line between them.Analyzing
the Reference policy[8],we found the following rules,related to message
queue(msgq) and other IPC objects:
#the ipc"read"ops (implicit single level)
mlsconstrain { ipc sem msgq shm } { getattr read unix
read }
(( l1 dom l2 ) or (( t1 == mlsipcreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsipcread ));
#the ipc"write"ops (implicit single level)
mlsconstrain { ipc sem msgq shm } { create destroy setattr write unix
write }
(( l1 eq l2 ) or (( t1 == mlsipcwritetoclr ) and ( h1 dom l2 )
and ( l1 domby l2 )) or ( t1 == mlsipcwrite ));
Obviously,user1 could not observe message queues,created by user2 as
the condition ( l1 dom l2 ) didn’t hold in the first mlsconstrain statement.
This is an example of"no-read-up"rule for IPC object classes.The second
statement explains why both users could not fetch oponent’s messages.It
is easy to see that user’s level and the level of message queue shoud be
equal (condition ( l1 eq l2 )).This rule controls unix_write permission that
was required by msgget system call and,therefore,both users were able
to fetch the messages,having exactly the same level.Using specified MLS
attributes,such as mlsipcreadtoclr,mlsipcread,mlsipcwritetoclr,mlsipcwrite
allows to get more privileges or even bypass these rules.For example,ml-
sipcwrite/mlsipcread attributes allow to perform writing/reading operations
on IPC objects,whatever security level they have.
We didn’t focus on the other IPC object classes,because,mlsconstrain
statements,that control access to these objects are implemented with similar
3.7.3 Application Support Analysis
To evaluate potential issues with support of applications in MLS environ-
ment we tried to analyze what happens if the same application is launched
by multiple users with different security levels.A lof of applications perform
3.SELinux Tools for MLS
reading/writing operations in such common directories as/etc,/var/log,
/tmp,but how the policy behaves in this case?To learn this,we used simple
test application that creates file in the specified directory and writes some
arbitrary data to this file.As testing directory,we chose directory/tmp,la-
beled with the full range of sensitivities and categories (i.e.s0-s15:c0.c1023).
In addition,we created new user user0 of the level s0,and used user1(with
level s1) fromthe previous examples.Then we launched the application from
the terminals of these users and got surprisingly different results:
drwxrwxrwt root root system
t:s0-s15:c0.c1023 tmp

[user0@localhost ~]$./test tmp [user1@localhost ~]$./test tmp
file succesfully created...Segmentation fault(core dumped)
data stored in the file.
The programwas successfully executed for user0 and failed for user1.Having
relabeled the directory/tmp,by changing its lowlevel to s1 we got completely
the opposite results(i.e.the programsucceeded for user1 and failed for user0).
drwxrwxrwt root root system
t:s1-s15:c0.c1023 tmp

[user0@localhost ~]$./test tmp [user1@localhost ~]$./test tmp
Segmentation fault(core dumped) file succesfully created...
data stored in the file.
This behaviour could be explained by the global mlsconstraint rule,related
to writing operations:[8]
mlsconstrain { file lnk
file fifo
file dir chr
file blk
file sock
file }
{ write create setattr relabelfrom append unlink link rename mounton }
(( l1 eq l2 ) or (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and
( l1 domby l2 )) or (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and
( h1 domby h2 )) or ( t1 == mlsfilewrite ) or ( t2 == mlstrustedobject ));
The first condition requires source and target low levels to be equal.There-
fore,in the first case only user0 didn’t violate the rule (user0 has level l1=s0
and tmp has low level l2=s0).In the second example only user1 matches
the condition(l1=l2=s1).MLS attributes can help us to solve this issue,but
it depends on the goals we want to achieve.For example,we can give tmp
directory permissions of the mlstrustedobject attribute that would allow pro-
cesses with any level write data to the directory.From the other side we
must consider what security affects it will cause and how trusted object is,
having such permissions.
From the above studying it becomes clear,that one of the main issues
that can make programs fail in MLS systems is writing operations related
3.SELinux Tools for MLS
to common directories.Except usage of attributes,there exists another ap-
proach to resolve this problem.It is polyinstantiation technology that will
be discussed in the next part of the thesis.
3.7.4 Polyinstantiation
In Unix systems there is a tradition to store temporary data in shared di-
rectories such as/tmp and/var/tmp.Long time it was not considered as a
security problem,however,in recent times it has been found that using such
approach is vulnerable to the following attacks[23]:
∙ So called race-condition attacks,using symbolic links
∙ Exposing file names that may contain sensitive information
∙ Attacks,performed by one user on another user
∙ Attacks,performed by a user on a daemon
∙ Attacks,performed by a non-root daemon on a user
Several attempts to solve these issues were considered(e.g.hiding file names,
controlling the ability to create hard-/sym- links )[24],but one of the most at-
tractive solution seems to be polyinstantiation.It is mechanism that allows
multiple versions of an object(mainly it relates to directories) within the
same virtual location.Currently,Linux Pluggable Authentication Module
(PAM) provides this functionality and was integrated with SELinux.PAM
supports polyinstantiation of directories using the Shared Subtree/Names-
pace services which are SELinux-aware[5].To enable polyinstantiation,PAM
can be configured,as follows:
∙ A pam_namespace module entry should be added to the appropri-
ate login configuration file(e.g.login,sshd,gdm) in/etc/pam.d/.For
example,ssh service(file/etc/pam.d/sshd) could be configured as the
auth include system-auth
account required pam
account include system-auth
password include system-auth
session optional pam
_ force revoke
session include system-auth
session required pam
session required pam
3.SELinux Tools for MLS
∙ Polyinstantiated directories are defined in the/etc/security/names-
pace.conf file.Each line of the file has the following format[5]:
polydir instance
prefix method list
The absolute path name of the directory to polyinstantiate (e.g./var/log)
is defined in polydir.Parameter instance_prefix defines the path name
for the polyinstantiated directory (target object of polyinstiation,e.g.
/var/log-inst/).Method determines the way polyinstiation should be
applied.It supports polyinstantiation,based on:user name,MLS level
and user name,security context.The last two methods are valid only
if SELinux is enabled.Finally,parameter list_of_uids is used to spec-
ify list of user names that will not have polyinstantiated directories.
Let us focus on the second method which uses MLS levels.The following
example shows how to configure polyinstantiated directories,based on user
name and MLS levels:
#polydir instance-prefix method list
/tmp/tmp/tmp-inst/level root,admin
/var/tmp/var/tmp/tmp-inst/level root,admin
We specified polyinstantiation for/tmp and/var/tmp directories.Polyinsa-
tiated instances will be located in the/tmp/tmp-inst and/var/tmp/tmp-inst
respectively.We also defined two users root and admin for whom the polyin-
stantiation will not be applied.Method level actually uses Linux user(not
SELinux) and MLS level assigned for the corresponding SELinux user.[5] For
testing purposes we used again user1(level s1) and user2(level s2).To check
what instances were created for each user we may login as root(or admin)
and list the/tmp/tmp-inst/directory:
[root@localhost tmp]#ls/tmp/tmp-inst/