In this lesson, we're going to discuss SELinux.
Now, in order to further mitigate the risk
of a security breach, several Linux distributions
provide an additional layer of security
on top of the original operating system.
Now, one of the best ways to stop a data breach
is to restrict the ability of granting access
or denying somebody's access
to a given resource object within your file system.
And this is where the idea
of Mandatory Access Control comes into play
and this is known as MAC, M-A-C.
Now, Mandatory Access Control is a system-enforced
access control mechanism that's based on
subject clearance and the object labels.
In this lesson, we're going to discuss
context-based permissions and security related technologies
as a security enhanced Linux, classified as MAC
or Mandatory Access Control systems,
to create those mechanisms on how to restrict access
to system processes into the files, directories, networks,
ports, and other things like that.
Now, context-based permissions refer to permission schemes
that are defined by various properties for a given file
or process, and it uses those properties together,
rather than in isolation to determine
whether to grant or deny access to a given user.
Now, in Linux, there are two main context-based
permission schemes that are available,
namely SELinux and AppArmor.
And both of these context-based permission schemes
leverage MAC to do their work.
Now, this differs from the default scheme inside of Linux,
which is known as DAC or Discretionary Access Control.
In DAC, each object has a list of entities
that are allowed to access it, whether these are systems,
processes, files, or users,
and the person who controls that
is actually the object owner.
They can make those changes directly
using things like change own (chown) or change mod (chmod),
depending on whether you want to change ownership
or permissions, and you can do that
in a discretionary manner.
Now, SELinux, on the other hand, doesn't allow DAC,
and instead it relies on MAC to do its permissions
and access control.
SELinux was created by the National Security Agency,
known as the NSA.
SELinux is the default context-based permission scheme
that's included inside of CentOS
and Red Hat Enterprise Linux.
By using SELinux, we have a way to provide
additional file system and network security
so that unauthorized processes cannot access
or tamper with our data, bypass our security mechanisms,
violate our security policies
or execute untrustworthy programs.
SELinux is used to enforce MAC on processes and resources
and enables information to be classified
and protected, based on its confidentiality
and integrity requirements.
This helps us mitigate the damage that could be caused
by information getting into the hands of a malicious user
or malicious application.
Now, SELinux defines three main contexts
for each file and process.
These are the User, the Role, and the Type.
The User context defines what users can access an object.
Different distributions provide different users,
but the most common ones include Unconfined_u,
which pertains to all users.
User_u, which pertains to unprivileged users.
Sysadmin_u, which pertains to system administrators,
and Root, which pertains to the Root user.
The Role context is our second area,
and this defines what roles can access a given object.
Now, SELinux users are authorized to be in a certain role,
and those roles are typically used to permit
or deny access to the given domain
or the given resources and processes.
To control this, there's a role called object_r,
and this applies to your files and directories.
Now, the third context we have is known as the Type context.
The Type context is the label portion of MAC,
and it's the most important context
for this fine grained access control that we want to achieve.
By using this type, it's a way of us grouping
objects together that have similar
security requirements or characteristics.
Now, another feature of SELinux
that's considered optional, is a fourth context,
and this is called a Level.
This Level is used to describe the sensitivity level
of a given file, directory, or process.
When we use levels, we call this
a multi-level security context,
and it enables you to further fine tune
and constrain access even when the main three contexts
are being fulfilled because this fourth one
of this level may not be.
Now, SELinux also has three different modes
that we need to cover.
These are called Disabled, Enforcing, and Permissive.
Now, in a disabled mode, SELinux is essentially turned off,
and so MAC is not going to be implemented,
and instead we're going to rely on the default DAC method
inside the file system.
Now, when we're using enforcing mode,
all the SELinux security policies are being enforced.
Therefore, the processes cannot violate
any security policies because we have them,
and they're being enforced.
The third one we have is known as permissive mode.
Now, in permissive mode, SELinux is enabled,
but the security policies are not enforced,
and this means that processes can bypass
the security policies.
Now, SELinux policy is going to be used to describe
the access permissions for all of your users,
programs, processes, files,
and devices that are going to be used
and acted upon by the operating system.
Now, SELinux can implement two different types of policies.
These are known as Targeted or Strict.
Now, the targeted policy is the default SELinux policy
that's used in Red Hat Linux and CentOS.
When we're using targeted policies,
processes that are targeted
are going to run in a confined domain.
And the processes that are not targeted will run
in an unconfined domain.
A strict policy is really the opposite of a targeted policy,
and this means that every subject
and object in that system is enforced
to operate on the MAC method.
So when you think about targeted,
this only applies to certain things on your operating system
that you really want higher levels of protection for.
If you go ahead and use the strict policy,
it's going to enforce MAC on everything on your system.
This is really complicated to set up
if you want to use this strict policy
because you have to go and look at everything
on the system, and what could be broken
by not having the proper access rights.
Now, once SELinux is enforced on a system,
there's going to be violation messages
that are going to be captured as part of an audit log
for you to be able to see what things people are doing
that aren't inside of your policies
that you're not allowing.
Now, these violations can occur
because somebody is trying to access an object
or a file they don't have access to,
or there's an action that goes against
an existing policy and it's being blocked.
When a system is first put under SELinux,
it's possible to get a lot of false violations
because your policies have to be tweaked
and configured and fine tuned.
Remember, SELinux is only as strong as the restrictive
profiles that you're creating.
So if you create good restrictive profiles
and you harden your applications, this can prevent
a lot of malicious attacks against your enterprise networks.