In this lesson,
we're going to discuss SELinux and AppArmor.
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 the Security-Enhanced Linux and AppArmor
are both 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
refered permission schemes
that are defined by various properties
for a given file or process.
And it uses those properties together, rather than 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 or change mod
depending on whether you want to change ownership
or permissions, and you could 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 can be caused
by information getting into the hands of malicious user
or malicious application.
Now SELinux defines three main context
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;
sysadm_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 roles.
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 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 there are several major commands
that you need to understand
if you're going to start configuring an SELinux environment.
This includes the semanage command.
The semanage command is used to configure SELinux policies.
The sestatus command is going to be used
to get the status of SELinux, including the policy type,
the mount point and other things like that.
The getenforce command is going to be used to display
which mode SELinux is currently running it.
The setenforce command is going to be used
to change the mode that SELinux is running in.
And then you can verify that
by using the getenforce command.
For example, if you entered setenforce 1,
this would enable enforcing mode.
If you set setenforce 0, this enables permissive mode.
You can also use the command getsebool.
And this will display the on or off status
of the SE boolean values,
which enable you to change policy configurations at runtime
without actually writing the policies directly.
If you want to change the on or off status
of an SE boolean value,
you can use the setsebool command.
Now you may be wondering
how you can list out the directory contents
along with each object security context.
And if you guessed that you're going to use the ls command,
you'd be right.
In this case, you're going to want to use ls-Z.
When you do this, it's going to list out the entire directory,
all of its contents and each object security context
in terms of SELinux.
Now, if you want to list out the running processes
along with each processes security context,
you can do that using the ps command by using ps-Z.
If you just want to check one specific process,
you can do that as well by typing in ps-Z
and the PID for the process you want to check.
Another command that you're going to use with SELinux
is known as chcon or change con.
Now this is going to change the context for a given file.
By issuing change con, and then -u, -r or -t,
this will refer to the user, the role or the type,
and then the context value you want to assign
and the file or directory you want to assign it to.
Now, if you make a mistake,
and you need to set that file back to its default context,
you can do that by using restorecon as the command.
And to do that, you'll simply type in restorecon
and the name of the file or directory.
As you can see, there are lots of different commands
associated with using SELinux.
It is somewhat complicated to set all this up properly,
but it does give you a lot better security.
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 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.
So you're going to want to use the sealert command,
which will make sure that all of your alert messages
for violations are being sent into the audit log.
Now unfortunately, the output of sealert
is a little bit difficult to read,
because it's meant for computers and not for humans.
So if you want to see things in a more human readable format,
I recommend you use audit2why instead.
audit2why is another command that allows you to go
and see what's in those logs
and what's happening in terms of these violations.
Now, in addition to the audit2why command,
you should also be aware of the audit2allow command.
The audit2allow command is a utility that you can use
to gather information from the logs
of all those denied operations and violations.
And then it will generate SELinux policy allow rules
for those denied operations.
This is really helpful when you're first installing a system
and you go ahead and turn it on
and you start seeing all the things that are being blocked.
And now you need to create allow rules
for all of those things
because they're things you actually wanted to happen
and not things you wanted get blocked.
To do this, you can run the command audit2allow -w -a
at the command line interface.
This will cause the audit2allow utility
to read from the audit log,
which is located at /var/log/audit/audit.log
and display in a human readable format
so you can understand a description
of all these different blocked activities.
Now, if you want to generate a loadable module
to allow this activity to occur,
you can then enter audit2allow -a -M and rule name.
And this is where you can define a rule name
that you want to use to identify this rule.
For example, you might call it allow web
or something like that.
Then this is going to create two files
in the current directory.
One is named rulename.pp
and the other one is called rulename.te.
Now te is a file type that is for type enforcement
and the pp file is what's known as a policy package file.
To load that policy package file into SELinux,
you're going to load that module and install it.
So you're going to use semodule-irulename.pp,
and this will implement your new SELinux allow rule
called rule name on your SELinux system.
Next, let's talk about AppArmor.
Now at the beginning of this lesson,
I mentioned that there were two
context-based permission schemas that we could use.
The first was SELinux and the second was AppArmor.
Now that we've covered SELinux, let's move into AppArmor.
Now AppArmor is an alternative
context-based permission scheme
and MAC implementation for Linux.
AppArmor provides the same fundamental services as SELinux,
but its approach is different
in a lot of significant ways that you should be aware of.
Now, the most overarching difference here
is that SELinux is considered very complex
and difficult to configure,
but AppArmor was designed to be much simpler.
Functionally, the main difference is that AppArmor works
with file system objects based on paths,
whereas SELinux actually references the inodes directly.
Now each executable can have an associated AppArmor profile,
and profiles are located in the /etc/apparmor.d/ directory.
Within this directory, there's going to be several text files
that are named in a path dot binary format.
For example, you might have the /bin/dig command
is one that you want to protect with AppArmor.
So its configuration file will be located
at /etc/apparmor.d/bin.dig.
Now within a profile, you can configure
two main types of rules.
One is called capabilities
and the second is called path entries.
Now capabilities provide the ability for that executable
to have access to some sort of system functionality.
For example, the net_bind_service capability
is going to enable the executable
to bind to a well known TCP/IP port
using a port number less than 1024.
Now these path entries, which is the second type
are going to be used to allow the executable
to access a specific file on the system.
So you can see that there's a capability and there's a path.
And capability our system functions
where as path entries are really giving you access
to a particular file on that system.
Now each profile can operate in two modes,
either complain or enforce.
When you're using complain mode,
this is going to make sure that the policy violations
are logged, but they're not blocked
and they're not prevented.
When you're using enforce mode,
those profile violations are both logged
and prevented or blocked.
Now the other thing we need to talk about is tunables.
Now tunables are a mechanism
for tuning your configurations inside of AppArmor
without having to adjust all of your different profiles.
These tunables are going to be stored in various files
underneath the /etc/apparmor.d/tunables directory.
The most common tuneable that you're going to use
is going to be in the /etc/apparmor.d/tunables/home file.
If AppArmor is denying access
to files in your home directory,
and your home directory is not in the /home,
then you're going to need to edit /etc/apparmor.d/tunables/home
accordingly to give you proper access to that.
Now some of the major commands that you can use
to configure AppArmor include things like apparmor_status.
This is a command that's used to display the current status
of your AppArmor profiles.
Another one you're going to see is aa-complain.
And this command is used to place a profile
into complain mode.
If you use aa-enforce, this is a command
that's going to be used to place the profile
into enforce mode.
aa-disable is a command used to disable a profile
and this will basically unload it from the kernel
and make it so it's not going to be enforced.
Another one you're going to use is aa-unconfined.
And this command is used to list out the processes
with open network sockets
that don't have an AppArmor profile loaded.
And so those are things you may want to look
at tightening up and giving yourself better security.
Now the bottom line is that AppArmor
can really be configured for any application
to reduces potential attack surface
and provide greater defense.
When you're using AppArmor,
it's going to be configured through these profiles
that are tuned to allow access
as needed by a specific program or container,
such as your different Linux capabilities,
network access, file permissions and more.
Each profile can then be run in either enforcing mode,
which blocks access to disallowed resources,
or complain mode, which only reports the violations
by logging them.
AppArmor is really used to give you a more secure deployment
by restricting what containers are allowed to do,
and be able to provide better auditing through system logs.
However, it's always important to remember
that AppArmor is not a silver bullet,
and it can only do so much to protect against exploits
and malware in your application code.
Remember, AppArmor is only as strong
as the restricted profiles that you're creating.
So if you create good restricted profiles,
and you harden your applications,
this can prevent a lot of malicious attacks
against your enterprise networks.