SELinux provides mandatory access control on Linux systems to confine processes and restrict what they can do. It works by labeling system resources like files, processes, and ports with security contexts. When a process tries to access a resource, SELinux checks if the process's security context is allowed to access the target resource based on the SELinux policy. This provides finer-grained access control than traditional Linux discretionary access control based on users and groups. The security context includes the SELinux user, role, and type (domain) that together determine the process's permissions.

1. PART 1
J A Y A N T C H U T K E
BY GNU GROUP INDIA
1

2. A LITTLE CONTEXT B4 BE START
The Five Golden Principles of Security
Know your system
 Principle of Least Privilege
 Defense in Depth
 Protection is key but detection is a must.
 Know your enemy.
2

3. INTRODUCTION
Most operating systems use what is called Discretionary
Access Control (DAC) to control how processes interact with
files and the way processes interact with each other.
On operating systems using DAC, users control the
permissions of the files they own.
The kernel enforces access control decisions based on these
security properties.
3

4. DAC (IN DEPTH)
Discretionary Access Control (DAC) defines the basic access
controls for objects in a filesystem. This is the typical access
control provided by file permissions, sharing, etc. Such
access is generally at the discretion of the owner of the object
(file, directory, device, etc.).
DAC provides a means of restricting access to objects based
on the identity of the users or groups (subjects) that try to
access those objects. Depending on a subject's access
permissions, they may also be able to pass permissions to
other subjects.
4

5. ( D A C )
5
~]$ ls -l file1 -rwxrw-r-- 1 use

6. WHAT COULD GO WRONG
Examples
* If a bug in the Apache web
server allows privilege
escalation to root, the whole
system has the potential to
be compromised.
* Lots of software daemons
run as the Linux root user or
have significant privileges on
the system. Errors within
those daemons can easily
lead to information leakage
or might even be exploitable
remote command execution
vulnerabilities.
Ordinary security policy is
too simplistic and there is
no way to enforce least
privilege (even though
we’ve layered on many
ways to try to enforce least
privilege).
6

7. ENTER SELINUX
One way of solving these problems is SELinux.
7

8. SELINUX HISTORY
8

9. BENEFITS OF RUNNING SELINUX
Fine-grained access control.
Stepping beyond traditional UNIX
permissions that are controlled at
user discretion and based on Linux
user and group IDs, SELinux access
decisions are based on all available
information, such as an SELinux
user, role, type, and, optionally, a
level.
SELinux policy is administratively-
defined, enforced system-wide, and
is not set at user discretion
Reduced vulnerability to privilege
escalation attacks.
SELinux can be used to enforce
data confidentiality and integrity, as
well as protecting processes from
untrusted inputs
9

10. SELINUX IS NOT
antivirus software,
a replacement for passwords, firewalls, or other security
systems,
an all-in-one security solution.
SELinux is designed to enhance existing security solutions,
not replace them. Even when running SELinux, it is important
to continue to follow good security practices, such as keeping
software up-to-date, using hard-to-guess passwords, firewalls,
and so on.
1 0

11. SELINUX ARCHITECTURE
• SELinux is a Linux security module that is built into the Linux
kernel.
• SELinux is driven by loadable policy rules. When security-
relevant access is taking place, such as when a process
attempts to open a file, the operation is intercepted in the
kernel by SELinux. If an SELinux policy rule allows the
operation, it continues, otherwise, the operation is blocked
and the process receives an error.
• SELinux decisions, such as allowing or disallowing access,
are cached. This cache is known as the Access Vector Cache
(AVC). When using these cached decisions, SELinux policy
rules need to be checked less, which increases performance.
• Remember that SELinux policy rules have no effect if DAC 1 1

12. SELINUX ARCHITECTURE
.
1 2

13. SELINUX ARCHITECTURE
• SELinux is a Linux security module that is built into the Linux
kernel.
• SELinux is driven by loadable policy rules. When security-
relevant access is taking place, such as when a process
attempts to open a file, the operation is intercepted in the
kernel by SELinux. If an SELinux policy rule allows the
operation, it continues, otherwise, the operation is blocked
and the process receives an error.
• SELinux decisions, such as allowing or disallowing access,
are cached. This cache is known as the Access Vector Cache
(AVC). When using these cached decisions, SELinux policy
rules need to be checked less, which increases performance.
• Remember that SELinux policy rules have no effect if DAC 1 3

14. SELINUX ARCHITECTURE
• SELinux is a Linux security module that is built into the Linux
kernel.
• SELinux is driven by loadable policy rules. When security-
relevant access is taking place, such as when a process
attempts to open a file, the operation is intercepted in the
kernel by SELinux. If an SELinux policy rule allows the
operation, it continues, otherwise, the operation is blocked
and the process receives an error.
• SELinux decisions, such as allowing or disallowing access,
are cached. This cache is known as the Access Vector Cache
(AVC). When using these cached decisions, SELinux policy
rules need to be checked less, which increases performance.
• Remember that SELinux policy rules have no effect if DAC 1 4

15. SELINUX ARCHITECTURE
• SELinux is a Linux security module that is built into the Linux
kernel.
• SELinux is driven by loadable policy rules. When security-
relevant access is taking place, such as when a process
attempts to open a file, the operation is intercepted in the
kernel by SELinux. If an SELinux policy rule allows the
operation, it continues, otherwise, the operation is blocked
and the process receives an error.
• SELinux decisions, such as allowing or disallowing access,
are cached. This cache is known as the Access Vector Cache
(AVC). When using these cached decisions, SELinux policy
rules need to be checked less, which increases performance.
• Remember that SELinux policy rules have no effect if DAC 1 5

16. MAC VS. DAC SMACKDOWN
Interactions among processes, objects and other processes is
controlled through the kernel security module.
Decisions by the kernel security module are based on all the
security relevant information available from the policy, and not
just authenticated user identity.
MAC allows you to provide granular permissions for all users,
programs, processes files, directories, devices, socket, ports,
fifos, etc.
1 6

17. SELINUX MODES
SELinux has three modes:
Enforcing:
SELinux policy is enforced. SELinux denies access based on
SELinux policy rules.
Permissive:
SELinux policy is not enforced. SELinux does not deny
access, but denials are logged for actions that would have
been denied if running in enforcing mode.
Disabled:
SELinux is disabled. Only DAC rules are used
define a security policy over all processes and objects. 1 7

18. SELINUX MODES
root# cat /etc/selinux/config
1 8

19. THE POLICY
1 9
Policy - A set of declarations and rules, telling the
SELinux core in the kernel what is permitted and how
to behave in different situations
Targeted policy - A policy based upon the paradigm,
that only a few selected applications should be
restricted by SELinux. All other activity relies on good
old UNIX security
Strict policy - A policy which attempts to control all
activity with SELinux

20. CONCEPTS
Everything in SELinux revolves around the Security
Context.
Well, with SELinux, it does depend on the context!
The context of a process is what identifies the process to
SELinux.
SELinux has no notion of Linux process ownership and frankly
doesn't care how the process is called, which process ID it
has and under which account the process runs.
All it wants to know is what the context is of that process.
2 0

21. THE CONTEXT
SELinux marks every process, file, pipe, socket, etc. with a piece
of information called the context.
SELinux allows or denies actions based upon rules saying ``a
process of context X can do so and so in relation with
something with context Y''
The context is completely unrelated to classic UNIX user ID,
group ID or whatever.
In particular: su, sudo and suid-bit games don't change the
context.
In short: In SELinux, the context is everything.
2 1

22. THE CONTEXT
• The context consists of three parts: The user, the role, and the
type
• In a commonplace policy, 99% of the decisions are made
based upon type only
• When the context applies to a process, the type is called
``the domain''
• There is no practical difference between a type and a domain
• All three components are just names. The policy rules gives
them significance.
• All users, roles and types can be applied to any object (given
the permissions), since they are just names
2 2

23. -Z IS YOUR FRIEND
How do you see a file’s or process’ security context?
Use the –Z option with Linux commands.
So, ls –Z will show you the security context files and ps –
efZ will show you the security context for the running
processes.
Want to know what your security context is? Do id –Z.
One of the powerful features of SELinux is that applications
do not need to be aware of SELinux.
Of the hundreds/thousands of rpm packages in RHEL 6, only
about 50 are compiled with SELinux awareness in them.
2 3

24. -THE FOODCHAIN: ROLES, USERS AND TYPES
• SELinux policy constrains which (SELinux) users can get
which roles
• It's common but not necessary, that each SELinux user can
and will have one single role
• The role limits which domains (types) its owner can enter
• RBAC (Role-Based Access Control): Restrict user's
permissions by allocating roles, which in turn limit their variety
of types, and hence limit their actions.
• The commonplace Linux policy is Type Enforced (TE), so
roles and users are of little importance.
• Upon login (not su), the shell process is given a SELinux user
and a role, typically unconfined_u and unconfined_r.
• These are most likely to remain throughout the session for all
child processes.
• Processes created by init or crond are likely to get system_u
and system_r
2 4

25. EVERYTHING GETS A LABEL
2 5

26. SELINUX AWARE APPLICATIONS
Applications used to view or manipulate security contexts
(Core Utilities). Examples of this are the ls for viewing
file context, ps for viewing process context, and find for
finding files based on context.
Programs required to set user session security context.
The login programs are the most obvious programs for
this: login, sshd, display manager such as gdm, and
cron
The SELinux core programs. These are used to
control/manipulate security context such as chcon,
setfiles, restorecon Those used to manipulate
policy such as load_policy, check_policy,
check_module, semodule, semanage, setenforce,
getenforce, setsebool, getsebool. 2 6

27. TARGETED POLICY
• Targeted policy is the default SELinux policy used in
Red Hat Enterprise Linux.
• Under the targeted policy, every subject and object runs in
the unconfined_t domain except for the specific targeted
daemons.
• Objects that are in the unconfined_t domain have no
restrictions and fall back to using standard Linux security, that
is, DAC.
• The daemons that are part of the targeted policy run in their
own domains and are restricted in every operation they
perform on the system.
• This way daemons that are exploited or compromised in any
way are contained and can only cause limited damage.
2 7

28. TARGETED POLICY
• For example,
the http and ntp daemons are both protected in the default
targeted policy, and run in thehttpd_t and ntpd_t domains,
respectively.
The ssh daemon, however, is not protected in this policy, and
consequently runs in the unconfined_t domain..
2 8

29. FEW COMMANDS
id –Z
ps -eZ | grep httpd
sestatus | grep "Loaded policy“
sestatus | grep deny_unknown
seinfo
2 9

30. Will cover in next part
• Policy implementation.
• Debugging
• THANKS
• GNU GROUP
3 0