Implementing Active Directory and Information Security Audit also VAPT in Fin...
PPT_Compiled
1. (Stevens Institute of Technology)
Adoption of SELinux for
Enhanced Security
Aseem Grover
Avineshwar Pratap Singh
Datong Peng
Gaurav Singh Chauhan
Paras Garg
Yuqi Zhu
2. Abstract— Linux security module can solve the problem of the deficiency of DAC. The availability of mobile phone is less
important relatively.
Index Terms— DAC, Linux Security Module, CIA, threat-asset matrix
—————————— ——————————
INTRODUCTION
This paper intends to show that SELinux module is
perfect for the Android system.Because all the mobile
phone can access the Internet via CDMA, and there are a
lot of mobile phone in the world, it is innately suitable
for launching a DDoS attack
It covers the deficiency of Dictionary Access Control and
the methods of improvement. DAC is common in Linux
operation systems, it can not eliminate the damage
caused by authorized program. It contains flaws as well.
So the privilege of the root has to be restricted. Thus, the
integrity of system will be enhanced. Meanwhile, the
system will distribute additional resources to run the
SELinux Module, that will stumble the availability.
From the data on the Internet, the analysis of attacks on
different assets shows that the availability of mobile
phone is less important. Stumbling availability of
Android will be tolerable. And the sacrifice of
availability results in higher security level for Android
system. Then the damage of the network caused by
mobile phones will be significantly reduced.
DAC
Dictionary Access Control is defined by Trusted
Computer System Evaluation Criteria. It is a rule to
restrict to access files based on the identity of the group
they belong to. A means of controlling access by users to
computer systems or to data on a computer system.
Different types of access exist. For example, “ read
access” would suggest that the user has authorization
only to read the information he or she is accessing,
whereas “write access ” would suggest that the user
has authorization to both read and alter accessed data.
In a Linux system, DAC can be checked by using
command
$ ls -l
Figure 1, an example of file
SELINUX MODULE
Figure 2, how is process checked in a Linux kernel
In those Linux systems with SELinux module, the
process will be re-checked by Linux Security Module
hook after the DAC checks as it is shown in figure 2. The
hook will call the SELinux Module as to give a
Process
Lookup data
Error
DAC checks
LSM hook
OK
SELinux
As it is shown in figure 1, add.txt is generated by user
datong. User datong is able to read and write this file.
Meanwhile, users are in the same group with user
datong are also able to read and write. But the other
users can only read the file.
DAC generally implements the management of file
system. But in some case, for example, with the Dirty
Cow, unauthorized users can access the file without
authorization.
Suppose that a user download an software from an
unknown source, which contains malicious code. He or
she knows nothing about the malicious code but eager to
run the software. When he or she install the software,
then the system will be hacked at once.
Datong Peng, Student
Motivations of Security and
Security Model of Linux
3. permission to the process if the resources are legal to
access. So there is a white list for the permissions of
processes access resources. For example, a evil process
want to acquire the root privilege. For some reasons, it is
authorized. Now even the process will damage your
system, it has to be checked by the SELinux module. If
the process is going to access somewhere forbidden, it
will be stopped. This is how SELinux protects the system.
Apparently, the security level of system will be enhanced
by adding extra security module, but stumble the
availability, because each innocuous process has to be
checked either.
EXPLOIT METHODS
Backdoor, denial of service,direct access attack,
eavesdropping, spoofing, tampering, phishing, social
engineering are the most common attacks nowadays.
The methods vary a lot, and the objectives are different
as well. Generally speaking, they can be divided into
three parts, confidentiality oriented, integrity oriented
and availability oriented as follow:
Figure 3, division of attacks
In the January to the June of 2015, there are 819 attacks
recorded on hackmageddon.com. The list on the website
shows when is there an attack, who is attack, whom is
under attack, what method is the attack, why raise the
attack.
Table 1 statistics of cyber attacks in the first half of 2015
In the table 1, the attacks are distributed in 5 categories.
They are the platform which can apply operation system.
For each cell of the table, it is divided into 3 levels: less
than 10 cases, more than 10 cases and less than 30 cases,
more than 30 cases. It can be quantified as 1,2 and 3 in a
nonlinear way respectively. Although it is a statistic of
the history, it indicates the possibility or frequency of an
attack on a certain asset. It can be easily found that the
values of server and cloud are very similar. This maybe
because the cloud plays a quite similar role to the server.
Similarly, the values of PC and cell phone.
THREAT-ASSETS MATRIX
Combine with table 1 and Figure 3, a simple summation
for each asset related to confidentiality, identity and
availability can be calculated out as the threat-assets
matrix which is shown in table 2.
Table 2 threat-asset matrix
For example, in order to calculate the threat index
confidentiality on servers, the reader should find out the
value of statistics of backdoor, direct access attack,
phishing, eavesdropping and social engineering. After
quantifying, the frequency of these 5 attacks are 2,2,2,1,2
respectively. So the sum is 9.
What need to be addressed is the availability of cloud
and mobile phone. It can be easily found that the value
of availability of cloud and cell are the lowest two values.
Besides the cloud, the low value of availability indicated
that it is less important. When the administrator is going
to change his or her security configuration of the mobile
phones, he or she can sacrifice the availability a little bit
in order to fortify the confidentiality and identity.
Backdoors DoS Direct Eavesdropping Spoofing Tampering Phishing Social
server <30 >=30 <30 <30 <30 <10 <10 <30
cloud <10 <30 <10 <30 <30 <10 <10 <30
router <30 >=30 <30 >=30 >=30 >=30 <10 <30
PC >=30 <10 >=30 <30 <10 <10 >=30 <30
cell >=30 <10 <10 <30 <10 <10 >=30 <30
server cloud router PC cell
Confidentiality 9 7 10 13 11
Integrity 8 6 11 11 9
Availability 7 4 7 7 5
4. CONCLUSION
Back to the Linux security module, it enforces the
identity of the operation system, but stumble the
availability. It will be perfect if apply SELinux onto the
mobile phones. For example, the Android system is a
Linux kernal operation system, which is basically used
on mobile phones or pads. The users will not configure
the system, so the SELinux will not appear to the user’s
eyesight. However, it indeed protects the system by
keeping the malicious code away from the system, but
no significant boring limitation from SELinux.
REFERENCE
[1] Exploit methods and definations,
https://en.wikipedia.org/wiki/Computer_security
[2] Introduction to DAC,
https://en.wikipedia.org/wiki/Discretionary_access_contr
ol
[3] Sven Vermeulen (2013), “SELinux System
Administration”
[4] Statistics of cyber attacks,
http://www.hackmageddon.com/2015-cyber-attacks-
timeline-master-index/
5. SE Linux - Mandatory Access Control (MAC)
Abstract – Understanding Mandatory Access Control (MAC), working of MAC and comparison between
working of DAC and MAC. Also, understanding implementations of MAC in different types of operating system.
Index Terms – MAC, DAC, SELinux, AVC, ACL, MSL, RHEL, LSM
—————————— ——————————
INTRODUCTION
THE objective of this document is to provide the
detailed information about SE Linux Mandatory
Access Control (MAC). It will be covering be basics
of Discretionary Access Control (DAC) and
Mandatory Access Control (MAC) in detail. The
document also covers difference between DAC and
MAC and advantages of MAC over DAC.
To understand MAC, first we need to understand
DAC and it how it works?
DISCRETIONARY ACCESS CONTROL (DAC)
Discretionary Access Control (DAC) allows
authorized users to change the access control
attributes of objects, thereby specifying whether
other users have access to the object. A simple form
of Discretionary Access Control (DAC) might be file
passwords, where access to a file requires the
knowledge of a password created by the file owner.
In Linux, the file permission is the general form of
Discretionary Access Control (DAC).
Discretionary Access Control (DAC) is the setting of
permissions on files, folders, and shared resources.
The owner of the object (normally the user who
created the object) in most operating system (OS)
environments applies discretionary access controls.
————————————————
Gaurav Singh Chauhan, Student: Stevens Institute of Technology,
Hoboken, NJ 07030, E-mail: gchauha2@ stevens.edu
This ownership may be transferred or controlled by
root/administrator accounts. Discretionary Access
Control (DAC) is controlled by the owner or
root/administrator of the Operating System, rather
than being hard coded into the system.
DEFINITION
The main purpose of MAC is restricting access to
objects based on the sensitivity. MAC system gives
the administrator full control over what is allowed
on the system and what isn't. It uses a policy-driven
approach on what processes are and aren't allowed
to do and what not, and enforcing this policy
through the Linux kernel. It checks if an operation
is allowed or not. Just like any normal Linux system,
DAC operations are performed in SE Linux too. All
the operations of MAC are performed after the
permission checks of DAC.
Gaurav Singh Chauhan, Student
6. WORKING OF MAC
When a subject, (for example, a process/user or an
application), attempts to access an object (for
example, a file/directory), first it goes through DAC
checks just like any other Linux system. If the
read/write/execute permissions are given to the
user, it moves to the next step i.e. MAC. For MAC,
when a subject attempts to access an object, policy
enforcement server in the kernel checks an access
vector cache (AVC), where subject and object
permissions are cached. If a decision cannot be
made based on data in the AVC, the request
continues to the security server, which looks up
the security context of the application and the file in
a matrix. Permission is then granted or denied, with
an avc: denied message detailed
in /var/log/messages if permission is denied. The
security context of subjects and objects is applied
from the installed policy, which also provides the
information to populate the security server's matrix.
7. IMPLEMENTATIONS
An NSA research project called SELinux added a
Mandatory Access Control architecture to the Linux
Kernel, which was merged into the mainline version
of Linux in August 2003. It utilizes a Linux 2.6
kernel feature called LSM (Linux Security Modules
interface). Red Hat Enterprise Linux version 4 (and
later versions) come with an SELinux-enabled
kernel. Although SELinux is capable of restricting
all processes in the system, the
default targeted policy in RHEL confines the most
vulnerable programs from the unconfined
domain in which all other programs run. RHEL 5
ships 2 other binary policy types: strict, which
attempts to implement least privilege, and MLS,
which is based on strict and adds MLS labels.
SUSE Linux (now supported by Novell)
and Ubuntu 7.10 have added a MAC
implementation called AppArmor. AppArmor
utilizes a Linux 2.6 kernel feature called LSM (Linux
Security Modules interface). LSM provides a
kernel API that allows modules of kernel code to
govern ACL (DAC ACL, access control lists).
AppArmor is not capable of restricting all programs
and is optionally in the Linux kernel as of version
2.6.36.
Microsoft Starting with Windows Vista and Server
2008 Windows incorporates Mandatory Integrity
Control, which adds Integrity Levels (IL) to
processes running in a login session. MIC restricts
the access permissions of applications that are
running under the same user account and which
may be less trustworthy. Apple's Mac OS X MAC
framework is an implementation of
the TrustedBSD MAC framework.[13] A limited
high-level sandboxing interface is provided by the
command-line function sandbox_init. See the
sandbox_init manual page for documentation.
The Android security model is based in part on the
concept of application sandboxes. Each application
runs in its own sandbox. Prior to Android 4.3, these
sandboxes were defined by the creation of a unique
Linux UID for each application at time of
installation. Starting with Android 4.3, Security-
Enhanced Linux (SELinux) is used to further define
the boundaries of the Android application sandbox.
CONCLUSIONS
1. To implement MAC, we need system
administrators and policies.
2. MAC provides enhanced security in SE Linux
as compared to general Linux DAC.
3. MAC only comes into picture after all the DAC
permission checks are successful.
REFERENCES
[1] Mandatory Access Control and its
implementations from
https://en.wikipedia.org/wiki/Mandatory_access_c
ontrol
[2] Discretionary Access Control (DAC) from
http://www.omnisecu.com/security/discretionary-
access-control-dac.php
[3] Working of MAC
https://www.centos.org/docs/5/html/Deployment_
Guide-en-US/ch-selinux.html
8. 1
SE Linux Security Components
Abstract— What the SE Linux required for any process or file to execute, how these required components have the impact on
the SE Linux decision making and why does SE Linux need these requirements for enabling enhanced security in the Linux
system.
Index Terms— Context, Label, Linux, Policy, SE Linux, Security.
—————————— ——————————
INTRODUCTION
HE concept of this document is to provide the de-
tailed information about SE Linux Security Compo-
nents. It will be covering all the important components
required by SE Linux to maintain the integrity and securi-
ty within the Linux system that Linux itself can not pre-
serve.
The document will provide the comprehensive view of
the features and the strategies adopted by SE Linux that
enhance the capability of the Linux system to defend itself
from the exploitation and controls the access to the re-
sources. How the nature and behavior of the resource get
evaluated in the Linux system in the presence of SE
Linux.
It also comprehends the functionality of the SE Linux
that how the resource executes in the SE Linux, how SE
Linux decides which process request is to be approved or
to be disapproved, how it marks the difference in trusted
and non trusted processes, how it enables the sensitivity
level inside the system, and how it changes the security
measures inside the Linux system.
SE LINUX CONTEXT
The first step in the SE Linux security is to put labels on
each 1entity in the Linux system. The label is like a pro-
cess or a file attribute which shows the context of the re-
source. The label could be any attribute such as owner,
group, or date of creation of a process or a file.
Definition
All the processes or files are labeled such a way that rep-
resents security relevant information. This information is
called SE Linux Context. SE Linux context can also be
interpreted as the collection of security relevant infor-
mation.
Need
SE Linux Context or Label is the most important aspect
for maintaining the SE Linux system, as all the SE Linux
policy decisions or access control decisions are based on
the label of the resource.
Fig. 1
Fig. 1 shows, how a process or a file is allowed or re-
jected by SE Linux on the basis of context which a process
or a file has.
SE Linux doesn’t care how the how the process is
called, or which process id it has, or under which account
the process run. All it wants to know is what the context
of the triggered process.
Elements
SE Linux contains additional information about a process
or a file
1. User, which represents the SE Linux user.
2. Role, which represents the SE Linux role.
3. Type, which represents the SE Linux type.
4. Level, represents the sensitivity.
Syntactically, all these elements are separated by colon ‘:’
in the given Linux command.
USER : ROLE : TYPE : LEVEL
Example, in the following commands the SE Linux con-
text which is used in a process to retrieve the information
about the current user.
$ id –Z
unconfined_u:unconfined_r:unconfined_t:s0
————————————————
Paras Garg is the Student with the Department of Computer Science, Ste-
vens Institute of Technology, 1 Castle Point Terrace, Hoboken, NJ 07030.
E-mail: pgarg2@ stevens.edu.
This thesis is a port of graduation program. It doesn’t mean to offense to any copy-
rights. General permission to make use in non profitable learning.
T
1The entity could be anything in a Linux system such as files, processes,
sockets, network interfaces, etc.
Paras Garg, Student
9. 2
SE LINUX USER
SE Linux user is different from the Linux user. Unlike the
Linux user information which can change while working
on the system, the SE Linux user remains the same even
when the Linux user itself has changed. Because of this
unchangeable state of the SE Linux user specifies the ac-
cess controls can be implemented to ensure that users
cannot work around the (limited) set of permissions
granted to them, even when they get privileged access.
But the most important feature of SE Linux user is
that it defines restrictions on the role which is allowed to
the user. Once a user is assigned as a SE Linux user, it is
not allowed to change the role that it isn’t meant to be in.
This is the role-based access control implementation of SE
Linux.
By convention SE Linux user is defined by a “_u” suf-
fix as shown in the commands below, although it is not
mandatory.
$ id –Z
unconfined_u:unconfined_r:unconfined_t:s0
SE LINUX ROLE
SE Linux role ensures that role-based control is enabled in
the SE Linux system as this control is vital in order to
keep the system secure, especially from the malicious
user attempts.
SE Linux roles are basically used to define which type
of process user can be in that implies SE Linux role de-
fines what a user can do or what cannot do.
Typically, there are five types of roles in any SE
Linux enabled system, but can also supports more and by
convention SE Linux role is defined by a “_r” suffix as
shown in the commands below.
$ id –Z
unconfined_u:unconfined_r:unconfined_t:s0
The types of roles which are present in SE Linux enabled
system are–
1. user_r – This role is for restricted users, and al-
lowed to have processes with types specific to
end user applications. Those users use to switch
Linux users are not allowed.
2. staff_r – This role is for non-critical tasks. This
role is best for the operators as tasks are restrict-
ed to some applications as restricted user.
3. sysadm_r – This role is for system administration
tasks. The role is best for system administrators,
which are allowed to perform various system
administration tasks and no end user applica-
tions are allowed to keep the system free from in-
fections as end user applications are considered
as untrusted and vulnerable.
4. syster_r – This role is for background processes
and allows various daemon and system process-
es. No other types of applications such as end us-
er applications and administration applications
are allowed.
5. unconfined_r – This role is for unconfined tasks,
best suited for the end users. This role allow a
limited number of applications and also allows
some privileged applications which are necessary
to operate other application, but has to be in
more or less unconfined manner. This privileged
access is only allowed to system administrators
those who wanted to protect certain applications
by keeping other system applications or opera-
tions almost untouched.
SE LINUX TYPE
SE Linux type is the most crucial and important element
among all four elements. Approximately over 99 percent-
ages of policy rules consist of rules based on the interac-
tion between the two types which even do not mention
about other elements (user, role and sensitivity).
SE Linux type is essential because it enforces the
mandatory access control system as SE Linux type defines
fine-grained access control of that process (called the do-
main) with respect to itself and other types such as pro-
cesses, files, sockets, network interfaces, etc. And this fi-
ne-grained access control is most likely responsible for
rejecting the access attempts by the processes.
SE Linux type enforcement enables the SE Linux to
control what an application is allowed to do which is
based on how the application got executed on the first
place. For example, suppose a web server is executed by
the system using init function and the same web server is
launched by the end user interactively. Even though the
executed process binary and the path is same, the process
executed by the system is considered as trusted while on
the other hand the process executed by the user is consid-
ered as normal behavior. And based on this considered
behavior system would be allowed to do anything what it
wanted to do and user would have the restricted set of
roles which it can perform.
By convention SE Linux type is defined by a “_t” suf-
fix as shown in the commands below, although it is not
mandatory.
$ id –Z
unconfined_u:unconfined_r:unconfined_t:s0
SE LINUX LEVEL
SE Linux level is also called the sensitivity label, it repre-
sent the sensitivity of the resource. The sensitivity label is
an optional element of the SE Linux context and in some
of the SE Linux enables the system to have this element
set disable by default.
SE Linux level is needed for Multi Level Security
support within the SE Linux. These sensitivity labels are
used for classification of resources and restriction of ac-
cess to resources based on a security clearance.
In the most documentation of any organization the
sensitivity label is marked as public, internal, confiden-
10. 3
tial, strictly confidential, or regulatory but the syntax of
SE Linux level does not allow to store values in this classi-
fication, instead of this sensitivity label accepts the num-
bers ranging from ‘0’ as the lowest confidentiality to any
number which a system administrator wants to assign as
the highest confidentiality value. This highest value con-
figured with the SE Linux policies when the policies were
built.
These sensitivity labels consist of two parts: a confi-
dentiality value (prefix with “s“) and a category value
(prefix with “c”) as shown in command lines below.
$ id –Z
user_u:user_r:user_t:s0.s6:c1.c6
In the above command lines ‘s0. s6’ represents the confi-
dentiality value of label as the first part ‘s0’ shows the
current sensitivity level, whereas the second part ‘s6’
shows the sensitivity clearance level and if this part is not
present then 0 is considered to be as sensitivity clearance
level. And ‘c1.c6’ represents the category value, it shows
the category is set from 0 through 6 and if this section is
not present in the command line then the category value
is considered as 0.
The parts of sensitivity label:
1. Confidentiality Value – It defines a process must
have minimum access control permit to access the
resource else the attempt would be denied.
2. Category Value – The idea behind this part is to
enforce multi-tenancy within the Linux system by
assigning same tags to processes and resources
having a similar tenant. This tagging allows the
similar tagged processes to access the targeted re-
source when the tag of process and resource
matches. And if the proper tagging is not assigned
or matched the process are not allowed to access
the targeted resources or processes.
SE POLICY
Policy is the set of rules that guide the SE Linux security en-
gine. It defines types for file objects and domains for pro-
cesses, uses roles to limit the domains that can be entered,
and has user identities to specify the roles that can be at-
tained.
The policy specifies the rules in that environment. It is
written in a simple language created specifically for writ-
ing security policy. Policy writers use m4 macros to cap-
ture common sets of low-level rules. There are a number
of m4 macros defined in the existing policy, which assist
greatly in writing new policy. These rules are prepro-
cessed into many additional rules as part of building poli-
cy.conf, which is compiled into the binary policy.
SE LINUX SECURITY
Label Based Access Control (LBAC)
LBAC is configured by the system administrator by creating
a security label components. This security label contains the
data which is required to match with the process which at-
tempt to access the resources. Insufficient or mismatch of
data will reject the access of resources.
Role Based Access Control (RBAC)
RBAC enforcement enables the SE Linux to control what
an application is allowed to do which is based on how the
application got executed on the first place.
User Based Access Control (UBAC)
UBAC prevent the user of SE Linux from changing the in-
formation while compiling and do not allow to access to the
resources or files of the different SE Linux user.
Multi Level Security (MLS)
MLS enforce the Bell-LaPadula configuration in SE Linux
that is based on security clearance level. It states that a
process can neither read anything with a higher confiden-
tiality level nor write anything to any resource with a
lower confidentiality level.
Multi Category Security (MCS)
MCS allows users to label process or files with categories
and allow all the processes to access the resource which has
the same assigned category. If category mismatch or doesn’t
assign properly, then no access to resources is granted.
REFERENCES
[1] Red Hat SELinux Guide (2005), Red Hat, Inc. Retrieved from
https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/4/html/SELinux_Guide/
[2] Robert Krátký and Barbora Ančincová, Red Hat SELinux User
Guide (2016), Red Hat, Inc. Retrieved from
https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/6/html/Security-
Enhanced_Linux/
[3] Sadequl Hussain (2014, September 25), DigitalOcean. Retrieved
from
https://www.digitalocean.com/community/tutorials/an-
introduction-to-selinux-on-centos-7-part-2-files-and-
processes#selinux-for-processes-and-files/
[4] Sven Vermeulen (2013), “SELinux System Administration”. Re-
trieved from
https://www.safaribooksonline.com/library/view/selinux-
system-administration/9781783283170/
[5] IBM Knowledge Center, IBM. Retrieved from
https://www.ibm.com/support/knowledgecenter
[6] Gentoo Foundation, Inc. Retrieved from
https://wiki.gentoo.org/wiki/SELinux/Tutorials/SELinux_M
ulti-Level_Security
11. SELinux Works in RedHatEL
Abstract—how SELinux is used in RedHatEL, how SELinux works in RedHatEL (Enterprise Linux) and why does SE-
Linux need these requirements for Multi-level security (MLS). In MLS environments and to determine the Architectur-
al considerations that impact security
Index Terms— RedHatEL Policy, SELinux Working, Concept, Type Enforcement, SELinux Error, Booleans, Fixing SELinux
issues, References.
—————————— u ——————————
WORKING WITH SELINUX
orking with SELinux In the beginning, when SELi-
nux was configured to actively constrain programs,
most applications experienced run-time failures.
What was missing were hand-crafted security policies.
Today, system administrators still find it necessary to cre-
ate appropriate security policies, as few applications
come with defined policy. As a result, each installation
crafts security policies it believes matches application
needs, with policy updates often required for every new
software release. When done incorrectly, resulting securi-
ty policies are too permissive (allowing exploitation),
overly strict, or simply wrong and can result in unneces-
sary application failures. Application developers are in
the best position to reliably assert the intent of the appli-
cation and to establish default security policy. To help this
effort, SELinux includes a rich set of fundamental protec-
tions. Red Hat provides many infrastructure improve-
ments, enabling application developers to provide appro-
priate default policies and common customization scripts.
When applications provide greater insight, system admin-
istrators can focus their efforts on securing the underlying
infrastructure, rather than spending time analyzing pro-
gram behavior and attempting to confine any potential
misbehavior of a compromised program according to se-
curity requirements
.
REDHAT ENTERPRISE LINUX POLICY
● In Red Hat Enterprise Linux 6, there are two policies
you'll generally see.
● “targeted” - the default policy
Ø Only targeted processes (there are hundreds) are
protected by SELinux
Ø Everything else is unconfined.
● “mls” - multi-level/multi-category security
Ø Can be very complex
Ø Typically used in TLA government organiza-
tions
SO HOW DOES SELINUX WORK?
Ø You can determine what policy your sys-
tem is set to use by looking at
/etc/selinux/config (which is also sym-
linked to /etc/sysconfig/selinux)
Ø You can check via /usr/sbin/sestatus
Ø You can check via /usr/sbin/getenforce
————————————————
W
1
The entity could be anything in a Linux system such as files, processes,
sockets, network interfaces, etc.
Aseem Grover, Student
12. SE LINUX CONCEPT IN RHEL
Two of the important concepts to understand with SELi-
nux are:
Ø Labeling
Ø Type Enforcement
LABELING
Ø Files, processes, ports, etc., are all labeled with an
SELinux context.
Ø For files and directories, these labels are stored as
extended attributes on the filesystem.
Ø For processes, ports, etc., the kernel manages the-
se labels
Ø Labels are in the format:
user:role:type:level(optional)
Ø For this presentation, we will not deal with the
SELinux user, role or level. These are used in
more advanced implementations of SELinux
(MLS/MCS).
Ø What we care about for today's presentation is
the type (remember, labeling and type enforce-
ment).
TYPE ENFORCEMENT
1. It probably makes sense for a process running in
the httpd_t context to interact with a file with the
httpd_config_t label.
2. Type enforcement is the part of the policy that
says, for instance, “a process running with the
label httpd_t can have read access to a file la-
beled httpd_config_t”
HOW SE LINUX DEAL WITH LABELS
Use the -Z argument to several commands to view con-
text. Many commands accept this argument:
● ls -Z
● id -Z
● ps -Z
● netstat -Z
You can use the -Z argument to create and modify files
and contexts, as well.
● cp -Z
● mkdir –Z
You can use SELinux aware tools like chcon or restorecon
to change the context of a file (more on this later). Con-
texts are set when files are created, based on their parent
directory's context (with a few exceptions). RPMs can set
contexts as part of installation. The login process sets the
default context (unconfined in the targeted policy)
● File transitions (defined by policy)
If an application foo_t creates a file in a directory la-
beled bar_t, policy can require a transition so that file is
created with the baz_t label.
Example: A process, dhclient, running with the dhclient_t
label creates a file, resolv.conf, labeled net_conf_t in a di-
rectory, /etc, labeled etc_t. Without that transition,
/etc/resolv.conf would have inherited the etc_t label.
1. Use the semanage command. It can be used to
manage SELinux settings for:
● login
● user
● port
● interface
● module
● node
● file context
● boolean
● permissive state
● dontaudit
SE LINUX ERROR
If you see an SELinux error, it means that something is
wrong! Turning off SELinux is like turning up the radio
really loud when your car is making a strange noise! It
may mean that labeling is wrong. Use the tools to fix the
labels. We'll talk more about that later.
It may mean that the policy needs to be tweaked.
● Booleans
● Policy modules
There could be a bug in the policy ● We need to know
about these! Open a ticket (do not file a Bugzilla report -
there are no SLAs around BZ).
You have been, or are being, broken into ● Man the battle
stations!
BOOLEANS
What Are Booleans?
● Booleans are just off/on settings for SELinux.
● From simple stuff like “do we allow the ftp server access to
home directories” to more esoteric stuff like “httpd can use
mod_auth_ntlm_winbind.”
To see all the Booleans, run getsebool –a
13. To set a boolean, run setsebool [boolean] [0|1]
● To make it permanent, pass the -P argument to set-
sebool
FIXING SELINUX ISSUES
• Install setroubleshoot and setroubleshoot-server
on machines you'll be developing policy modules
on. They drag in a bunch of tools to help diag-
nose and fix SELinux issues.
• Reboot or restart audited after you install.
References
• SELinux Guide:
http://docs.redhat.com/docs/enUS/Red_Hat_E
nter-
prise_Linux/6/html/SecurityEnhanced_Linux/i
ndex.html
• Fedora Project SELinux Docs:
http://fedoraproject.org/wiki/SELinux
• fedora-selinux-list (mailing list):
https://www.redhat.com/mailman/listinfo
• Red Hat Training - Red Hat Enterprise SELinux
Policy Administration:
http://www.redhat.com/training
• http://access.redhat.com has several videos
about SELinux. Dave Egts and Dan Walsh have
covered topics from confining users to sandbox-
ing.
• Dan Walsh's blog:
http://danwalsh.livejournal.com/
14. Practical SELinux
Abstract— How to go about implementing a MAC-based solution (specifically SELinux) for enhancing an operating system’s
security. Even though our focus is targeted on RHEL, it is purely so for demonstration purposes and one can choose any other
distribution (mobile/desktop/server/et cetera) to enhance its existing security model using SELinux.
Index Terms— DAC, MAC, SysAdmin, RedHat, Android, SELinux.
APPLICABLE GIST
When I’m talking about gist, I am trying, as
simplistically as possible, to give a feel about SELinux in a
sense that it is really worthy to get a hang of it.
Propagating that understanding into everybody’s mind
might not be a straight-forward concept but, it might not
be that difficult if I can provably demonstrate how
security can be achieved using SELinux. Such a
demonstration is supposedly going to help you in a sense
that it might invigorate an understanding as to why
people should really talk about SELinux.
This portion of the document will provide a decent
view of the features of SELinux from a practical
standpoint i.e., you’re supposed to have a contextual
understanding of SELinux if not exhaustive. That kind of
understanding should have been developed by now if
you’ve followed the document from the very start with an
open mind.
After reaching the end of this paper, one might feel
that either the default security of *nix systems aren’t
really required since SELinux is nailing what DAC
(Discretionary Access Control i.e., the default security of
*nix systems) was supposed to do, or, one can feel
complemented in terms of the understanding he was
possessing till now, or anything else which I am missing.
At the end of this preface I’d say it doesn’t really matter if
you’re interested in security because, whatever digital
repercussions are there, security is/was/will be, an
implicit piece of it and one can always play some part.
MOTIVATION
It is important to understand the motivations before
diving into SELinux (or anything for that matter). Here
are some of them.
Enhancement of existence
*nix systems (mobile/desktop/servers/et cetera) can rely
on DAC for their security. In the light of events which
had taken place (for example, issues due to unintended or
unsuspecting misconfigurations) in the past, it
necessitates an existence of a better model for security.
That is achieved by SELinux i.e., enhancement (not an
elixir!).
————————————————
Anti-awareness stems distrust
People hear about Linux (and other flavours) being a
great (fast and secure) operating system and suddenly
they hear/read about massive breaches of Linux-based
systems because of some kind of (unknown/pseudo-
fixed/latent) vulnerability was exploited by malicious
actors. It’s important to rely on the highest level of
security model available, at least on mission-critical
places. Accepting a fact with a pinch of salt that if there
would have been a better security model, such mishaps
could have been warded-off or delayed. That’s possible if
one is aware of an existing but better security solution
(SELinux).
Easier than it seems
Usually choosing SELinux as a security model means
having individuals with an un-ambiguous understanding
of it. Generic system administrators don’t feel there is a
need of having SELinux as their security solution as there
is a much greater amount of setup/initial work to do
which they relate with complexity without bringing any
significant gains. Since “complexity is not labour” there is
a lot to gain if one chooses to go with SELinux (essentially
a MAC-based solution).
SECURITY STATE W.R.T. SELINUX
What we’ll be looking in this part are as follows:
1.) Strengthening posture of a webserver. Selectively
we will be looking at apache (the webserver)
running on a system (RHEL 7.3) deployed on a
cloud service (AWS). Every package used in this
demonstration is current as well as the
distribution (RHEL here) itself.
2.) How SELinux cannot always help if one makes a
known or an unsuspecting bad choice.
Selectively, this will be demonstrated using
nagios (an open-source application that monitors
networks, network devices and infrastructure as
a whole) running on a similar setting as above. It
is worth noting that nagios is highly preferred by
anyone who feels a need of having a similar
solution, worldwide. You’re free to check the
statistics.
3.) Pervasive failures of any security solution
(including SELinux) if an underlying operating
system is attackable.
Avineshwar Pratap Singh, Student
15. This will be shown using a mobile device (Note 5
running Android 6.0.1).
STRENGTHENING POSTURE
The steps which I will show have been taken irrespective
of any specific thought-process, i.e., they’re not taken to
prove my point rather to show a possibility as to how
SELinux can play an essential role.
Steps I took were as follows:
1.) Update the distribution (RHEL 7.3 here).
2.) Install apache/httpd (repo-based installation).
3.) Start the service.
4.) Allow inbound access on port 80 through
security group and/or firewall and/or iptables,
in an irrespective but incremental order if
needed. Port 443 (HTTPS) access isn’t needed for
this demo.
There are two commands which can be used to place a
file (everything is a file!) from a place to another place in a
*nix-type system. When we use the “cp” command, we’re
copying. When we choose the “mv” command, we’re
moving. Both can help us in achieving the same goal
however, SELinux responds to them differently i.e., the
affect will be visible only in a system having SELinux in
enforcing mode. When we use “cp” command, context is
transitioned and when we use “mv” command, it’s not.
You should know what it means by context w.r.t. SELinux
by now.
Through “ps -eZ | grep httpd” command, I showed that
the apache daemon process (named httpd) is running (and
it is in some context which is consistent to the default but
defined policies).
Using the “getenforce” command, we saw that the system
(precisely SELinux) is in enforcing mode.
I created three files using the “echo” command.
As the files were created in some directory where we
currently are, we can check the context of those files using
the “ls -lZ” command.
I then copied a file in the default apache directory which
apache uses to serve resources on the web. Upon
checking the statistics of that file (using the “stat”
command), we saw its context has been changed (termed
as context-transition). We can also see that file’s
permission (644). When we will try to visit the cp’ed file,
it will be accessible (first DAC allows it and then
SELinux/MAC allows it due to proper context).
Now I moved another file in the default apache directory.
Upon checking the statistics of that file, we saw its context
has not been changed. We can also see that file’s
permission (644). When we will try to visit the mv’ed file,
access will be blocked (first DAC allows it and then
SELinux/MAC blocks it due to improper context). Either
SELinux has to be disabled (an admin action) to make
that file accessible on the web or its context has to be
transitioned (so the execution will happen in a
containerized environment). To prove the point of having
SELinux (and that DAC has a shortcoming), I made the
SELinux to go in the permissive (using “setenforce 0”)
mode and the file was accessible on the web.
SELINUX CANNOT ALWAYS HELP
We’ve understood that SELinux is a good mechanism and
one can rely on it (SELinux does cause a minute
performance degradation). SELinux, however, cannot
help under situations stemmed from, say, a bug
exploiting a vulnerability to do privilege escalation, et
cetera. Specifically, I showed a version of nagios
vulnerable to this problem (generally irrespective of any
other factor). This version is second to the newest version
and statistically speaking how much people rely on
nagios, there might be a possibility that at a good number
of places this is still exploitable (locally only though). I am
running a PoC exploit script (credits to the original
author). This script has to run as a user named nagios on
the system having nagios installed. Upon meeting a
certain condition, this script escalates privileges and
becomes root user.
16. In this paper, it is not worth to discuss why this exploit is
happening because such a knowledge might propel
similar attempts in a newer fashion. If you have an
intermediate and above experience with *nix systems,
you will understand the below screenshots. These
screenshots are from my personal setup and isn’t going to
harm anyone. If this is perceived as a scorning attempt on
nagios developers or the company’s image as a whole, I
would like to extend my support to the nagios community
as whole in the manner they want. This is purely for
fulfilling my educational desires.
A user named nagios should not be able to read the
/etc/shadow file as it contains encrypted passwords of the
users; they can be brute forced to retrieve the passwords
and impersonate a user thereby even doing some kind of
irreparable damages. However, root user can read the file.
We see in the above image that indeed nagios’s read
access is denied. I will now, on a separate terminal, log in
as root and I will stop at the step where if I’d press return
key, I will restart the nagios service/daemon. On this
terminal, I will execute the exploit.sh script.
On this terminal, upon executing the exploit script, I will
wait for the nagios service to restart. From the other
terminal on which I am logged in as root, I’ll restart the
service by pressing return from my keyboard. In a blink
of an eye, some magic will lead the user named nagios to
become the user named root. At this point, I effectively
own the system as a whole. The first step I will do is to
disable the SELinux; the protection is over but logging
will still be done until SELinux is disabled (not just
permissive) which is possible after a system restart.
Showing how this exploit works or sharing the exploit
code, might not be a constructive gesture; I will not be
including any more information about this. Refer to this
diagram and imagine what an escalation is capable of.
PERVASIVE FAILURES
When bug is uncovered, it can be a newly introduced one,
a failed fixture, or a latent one lying there from may be
decades. Under any situation, since our SELinux is trying
to protect a system which can be exploited at a lower
level, bypassing any measure is trivial. It can lead to
multiple categories of exploitation and SELinux will be
there doing nothing reason being nobody previously
knew about that vulnerability and SELinux’s creators
assumed the underlying OS to be KBF or known-bug-free.
There is a demonstration available on my YouTube
channel showing how I am able to write to a file whose
write access only belongs to the root user while I am some
random user. SELinux again, is in enforcing mode here
(which I haven’t explicitly shown in the video). I
exploited a vulnerability named DirtyCOW (Dirty Copy-
On-Write) for achieving this goal. A majority of (Android)
mobile devices will remain vulnerable to this for several
upcoming months considering the release cycles of
fixtures by manufacturers. As it is publicly known that
this exploitation will lead to bypass of any form of
security measure, every possible channel of receiving
data in any form can lead to an exploitation (including
app updates and installs from official sources, unofficial
marketplace apps, et cetera).
CONCLUSIONS
Upon concluding this portion, I’d like to state some
concrete facts:
1.) SELinux can turn out to be a blessing in disguise,
say, if someone left a configuration file and it is
out of context w.r.t. to SELinux. In general, it is
going to be a great protector.
2.) When we stress on the importance of having
SELinux, we’re stressing on the importance of
having a MAC-based solution to protect an
existing DAC-type solution. AppArmor is another
MAC-based solution but practicality has shown
that under certain situations, AppArmor can be
short as well; both’re have proponents.
3.) SELinux is not an elixir is a sense that it cannot
handle problems it was not supposed to handle.
Having SELinux is better anyway.
REFERENCES
[1] Red Hat SELinux Guide (2005), Red Hat, Inc. Retrieved from
https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/4/html/SELinux_Guide/
[2] Robert Krátký and Barbora Ančincová, Red Hat SELinux User
Guide (2016), Red Hat, Inc. Retrieved from
https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/6/html/Security-
Enhanced_Linux/
[3] Sven Vermeulen (2013), “SELinux System Administration”
17. What SELinux adds to Linux (including overheads)
and Android and its future scope.
Yuqi Zhu, Student
INTRODUCTION
This paper will focus on describe the
difference between SELinux and Linux from
different aspects include the kernel, the
system performance, and how to apply
SELinux on Android system.
According the data come from Internet, the
performance of run a MySQL benchmark
with database working on an 8-core, RedHat
Enterprise Linux system can show the result
of SELinux slows down system performance.
At the last part, the difference between
SEAndroid and common Android will be
shown from the aspects of the origin of
SEAndroid, the security mechanism of
SEAndroid, the benefit of SEAndroid and the
future scope of SEAndroid.
THE ORIGIN OF SELINUX
Before Linux 2.6, SELinux is a Linux kernel
security module, this module offers a flexible
mandatory access control (MAC) mechanism
for security policies.
This concept can be traced to the earlier
projects of United States National Security
Agency.
The original security module of SELinux is
FLASK, which is Flux Advanced Security
Kernel was designed by National Security
Agency. At that time, FLASK was service for
DTOS system. Then, based on the future
scope of Linux system, National Security
Agency implemented FLASK on Linux, here
comes out SELinux.
After Linux2.6, SELinux was been
embedded into Linux kernel. To make sure
Abstract— What SELinux adds to Linux, cost of SELinux, what is SEAndroid, the future scope
of SEAndroid.
Index Terms— DAC, MAC, Kernel, System performance, SEAndroid, Android Application
Sandbox.
WHAT SELINUX ADDS TO
LINUX
18. the security performance, SELinux have
modifications on Linux kernel, and adds
some User-space tools.
Now let us focus on kernel, common Linux’s
kernel is a standard open Source Linux with
Discretionary Access Control (DAC) kernel
architecture.
For SELinux kernel architecture, it based on
Linux kernel but adds some utilities to
combine a Mandatory Access Control (MAC)
architecture.
figure 1.1
figure 1.2
COST OF SELINUX
Although SELinux does well on security, but
it slow down system performance, the reason
is it is performing a full compile of policy
when you are running the command.
Here is an example comes from Internet,
which can show the result of SELinux slows
down the system performance:
The system is an 8-core system, RedHat
Enterprise Liunx6.2, researcher ran the
MySQL benchmack on the system twice with
SELinux enabled and disenabled to recorded
OLTP test result.
Throughput:
figure 2.1
Response time:
figure 2.2
According to the test data, when the number
of threads increase, especially over 8 threads,
throughput of the system with SELinux
enabled begin to decrease linearly. And the
slopes of response time’s linear functions
also show an obvious difference.
THE ORIGIN OF SEANDROID
As we know, Android system is based on
Linux kernel. But SELinux cannot fully
implement on Android. Hence there is a new
19. project that enable the use of SELinux on
Android system which is SEAndroid. The
first version of Android that support SELinux
is Android 4.3, and Android 5.0 is the first
version with SEAndroid.
SEANDROID MECHANISM
SEAndroid focus on protect the resources of
Android system, those resources distributed
in different subsystems and they are
variously, for example files, threads and IPC.
Some of them should be protected careful
because of the user space runtime between
Android and common Linux.
figure 3.1
SEAndroid mechanism is supported by user
space and kernel space. The SELinux LSM
(Linux Security Module) focus on mandatory
access control, and the SEAndroid policy in
charge of resource security access policy.
Those policies are based on Security Context.
Security Server will load those policies into
SELinux LSM at the time of system start.
Security Server will index or another hand,
say check the security context in user space
and do the security context in kernel space.
figure 3.2
With enable SELinux in Android, the system
can avoid malicious system attack from super
user.
FUTURE SCOPE
SEAndroid brings flexible MAC to Android,
the consequence can be concluded by
following:
a. Strictly limited super user.
b. Reduces the risk of critical system
processes being attacked.
c. Enhance Android Application Sandbox.
d. Enable the modification of Application’s
privileges (which was settled while the
Application installs).
Although the open nature of Android’s
ecosystem enabled threats always be more
prevalent under Android system. But
SEAndroid is a big step to improve the
security of smartphone. And it will be the
more and more important role for Android
security in the future.
