Ethical Penetration Cybersecurity

Testbed for Educational Purposes

CENG685-
Information
Security
Lab 05 – Mandatory Access
Control (MAC) & Role Based
Access Control (RBAC)
1. Objectives
In this lab, we will study the Mandatory Access Control (MAC) Mechanism supported in
Linux. Mainly, we will cover Apparmor module of Ubuntu and SELinux of Fedora. Note that
the BLP (Bell-LaPadula) model is only supported in SELinux.

2. Mandatory Access Control

People are familiar with Discretionary Access Control (DAC) that restricts access to resources
based on users and/or groups they belong to. A user is in control of who can access and modify
a resource. In other words, access to a resource is at the user’s discretion. This creates a problem
where a compromised program inherits access controls of the user and so can-do things that
users can do. Thus, if a compromised process happens to be running with effective superuser
privileges, an attacker can take full control of the system. This is undesired, to say the least.

Mandatory Access Control systems like SELinux or Apparmor go way beyond Linux
permissions which are discretionary and can be ignored by root. Unlike DAC permissions, with
MAC even root has to abide by some predefined policies. So even if a program runs with
effective root privileges, it cannot do anything other than it is allowed to do.

For implementing MAC, Linux has Linux Security Modules (LSM) integrated into the kernel.
LSM is a generic framework such that different MAC extensions can be implemented by
loading a different kernel module. Some of the official Linux kernel MAC extensions are
Security Enhanced Linux (SELinux), Simplified Mandatory Access Control Kernel (SMACK),
Application Armor (Apparmor), FireJail, etc.

3. Apparmor - MAC Module (use Ubuntu VM)

In Ubuntu, Apparmor is installed and enabled by default. The Apparmor profiles get loaded
when system starts. What are profiles? Apparmor confines programs to a limited set of
resources. This confinement is provided via security policies called profiles loaded into the
kernel. When profile rules are violated, Apparmor can be set to either enforce the profile or
complain:

▪ Enforce – In the enforce mode, system begins enforcing the rules and report the
violation attempts in syslog or auditd (only if auditd is installed) and operation will not
be permitted.
▪ Complain – In the complain mode, system doesn’t enforce any rules. It will only log
the violation attempts.

Apparmor is designed to work with the standard Unix DAC permissions while being easy to
use and deploy, by allowing an admin to confine only specific applications. Using the most
basic Apparmor tools an administrator can create and deploy Apparmor profiles to restrict
access for specific processes. For example, one could restrict the web browser to only let users
access files in their home directories. This would prevent a scenario where Alice would try to
upload or share files owned by Bob without his knowledge.

Profiles completely define what system resources individual applications can access, and with
what privileges. A number of default profiles are included with Apparmor. Apparmor profiles
for even very complex applications can be deployed successfully in a matter of hours. In the

1
next section, we will show the main Apparmor tools.

3.1 Apparmor Configuration

To get started, make sure the service is running in Ubuntu, use this command (root or sudo):
systemctl status apparmor # Checks status of Apparmor service and tells if it is enabled on boot

To start/enable the service, use:

systemctl start apparmor # Starts the service
systemctl enable apparmor # Makes Apparmor start on boot

To install additional Apparmor utilities and useful commands such as control profiles, look for
activities and create profiles, type:
sudo apt-get install apparmor-utils

3.2 Getting Started

You can view the current status of Apparmor and all the profiles. To do so, login with root user,
run aa-status in the terminal and read the output carefully. You will be able to see a number
enforced profiles, some others in complain mode and some unconfined processes.

Enforced means whatever in this profile must be enforced even for root. What this means is
that Apparmor will monitor the processes that match these profiles and decide if a specific
action is permitted or denied by the policy.
When a profile is in complain mode, Apparmor allows it to perform (almost) all tasks without
restriction but it will log them in the audit log as events. This is useful when you are attempting
to create a profile for an application but you are not sure what things it needs access to.
The unconfined status on the other hand will allow the program to perform any task and will
not log it. This usually occurs if a profile was loaded after an application is started, meaning it
runs without restrictions from Apparmor. It’s also important to note that only processes that
have profiles are listed under this unconfined status, any other processes that run on your
computer but do not have a profile created for them will not be listed under aa-status.

3.3 Example of Enabling Profiles

How to confine the ping even for root?

Try to ping 127.0.0.1 in root and it works.

Then locate ping, run: which ping. This will return that the process ping is located in /usr/bin

Create an Apparmor profile for ping: aa-autodep /usr/bin/ping (later on we will see aa-genprof)

Go back and run for aa-status, you see one new profile for ping in complain mode.
Run aa-enforce /usr/bin/ping to enforce the new policy related to ping, now run again aa-status
and you will see more enforced profiles.

Ping as root then permission will be denied, thus MAC is working because the profile was

2
enforced. We can tightly control what an application can do using aa-logprof to see the logs that
ping was doing.

To see what we have in ping profile, run cat /etc/apparmor.d/usr.bin.ping (notice that the path
to the profile related to ping uses ‘.’ instead of ‘/’) . The profile (policy) states that if ping is
trying to do something other than what we have in its profile, it will be denied.

3.4 Disabling Profiles

Sometimes, it's useful to disable a profile and to test again if any bug persists:

# disable a profile temporarily

$ aa-disable /etc/apparmor.d/usr.bin.ping

# after testing, re-enable it in complain mode

$ aa-complain /etc/apparmor.d/usr.bin.ping

# or in enforce mode
$ aa-enforce /etc/apparmor.d/usr.bin.ping

# to test if AppArmor has been correctly enabled

$ aa-enabled (this will return Yes if enabled)

# to disable AppArmor by unloading all profiles for the current session

$ aa-teardown

3.5 Conclusion

The key to a successful Apparmor deployment is to set profiles to complain, then enforce.
Careful log examination will give you the minimal paths and capabilities needed for successful
program operation. By assigning these and no more you will increase your system security.

3.6 Assignment

Watch this video and submit the experiment that starts at time 2:55. Explain the steps to
create an Apparmor profile for a shell script.
https://www.youtube.com/watch?v=HUIgljqgCRA
In this video, you have to create a script, and generate a profile for it using genprof, edit the
profile later on to see how the policy or profile is enforced. Note that you can add capabilities
in the profile such as capability dac_override, etc.

3
4. SELinux - MAC & RBAC (use Fedora VM)

To download the Fedora VM image, use this link or any other link of your choice:
https://sourceforge.net/projects/linuxvmimages/files/LVM/Fedora_33.zip/download
Default Username: fedora and password: fedora
To become root, run: sudo su -

Why SELinux? We’ve seen that Apparmor works using file paths, its configuration can be
easily adapted, and it does not require re-labeling of the file system. SELinux on the other hand
attaches labels to all files, processes and objects and is therefore very flexible. However,
configuring SELinux is considered to be very complicated and requires a supported filesystem.

The advantage of SELinux is that it implements either Type Enforcement (TE), Roles Based
Access Control (RBAC) or Bell-La Padula Model Multi-Level Security (MLS) covered in
class.
Note that there is a known issue that does not allow the Ubuntu kernel to boot after installation, that is
why it is recommended to use Fedora where SELinux comes pre-installed and activated.
To install SELinux in Ubuntu:
$ sudo apt install policycoreutils selinux-utils selinux-basics
To activate SELinux:
$ sudo selinux-activate
Then reboot the system and wait until it finishes relabeling (I could not relabel in Ubuntu! That is why I
decided to download the above Fedora VM)
If relabeling works, the next step is to set SELinux to enforcing mode:
$ sudo selinux-config-enforcing
Reboot again and check SELinux status:
$ sestatus
To disable SELinux open up the /etc/selinux/config configuration file and change the following line:
From SELINUX=enforcing To SELINUX=disabled and reboot your system.

4.1 Getting Started

SELinux works by using Labels and Type Enforcement. This can be also described in the
format: [SELinux User]:[SELinux Role]:[SELinux Domain/Type label]:[SELinux MCS/MLS Label]

For example, “sshd” service executable configuration directory is labeled ssh_exec_t as seen
below using the command utility ls -Z as shown below:

Type Enforcement is the part where the policy dictates if for example within ssh process
context running label ssh_exec_t to interact with a ssh file label.

1. User: The SELinux user identity. This can be associated to one or more roles that the
SELinux user is allowed to use.
2. Role: The SELinux role. This can be associated to one or more types the SELinux user
is allowed to access.

4
 3. Type: When a type is associated with a process, it defines what processes (or domains)
the SELinux user (the subject) can access. When a type is associated with an object, it
defines what access permissions the SELinux user has to that object.
4. Level: This optional field can also be known as a range and is only present if the policy
supports MCS or MLS.

The modes of operation and the policy types are embedded inside “config” file which controls
the state of the SELinux on the system. The file can be accessed using an editor:

gedit /etc/selinux/config

There are two policies that can be used:

1. Targeted Policy: is the default policy where targeted processes are protected.
2. Minimum: only selected processes are protected.
3. Multi-Level/Multi Category Security-(MLS) Policy: Can be enabled.

SELinux has three modes of operation:

1. Enforcing: SELinux denies access based on SELinux policy rules.

2. Permissive: SELinux does not deny access, but denials are logged for actions that
would have been denied if running in enforcing mode.
3. Disabled: SELinux is completely disabled.

Use the setenforce utility to change between enforcing and permissive mode. Changes made
with setenforce do not persist across reboots. To change to enforcing mode, as the Linux root
user, run the setenforce 1 command. To change to permissive mode, run the setenforce 0
command.

Use the getenforce or sestatus commands to check the status of SELinux. The getenforce
command returns Enforcing, Permissive, or Disabled. The sestatus command returns the SELinux
status and the SELinux policy being used.

To permanently change the states and modes in SELinux, follow the steps here:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-
enhanced_linux/sect-Security-Enhanced_Linux-Working_with_SELinux-Changing_SELinux_Modes

5
Note that SELinux errors and problems occur as result of the following miss-configurations:

▪ Wrong Labeling: Different tools can be used to fix this issue such as chcon and
restorecon.
▪ SELinux Policy Tuning: Creating and updating policy modules and working with
Booleans.

4.2 About Targeted and Multilevel Security Policies

An SELinux policy describes the access permissions for all users, programs, processes, and
files, and for the devices upon which they act. You can configure SELinux to implement either
Targeted Policy or Multilevel Security (MLS) Policy.

Targeted Policy applies access controls to a limited number of processes that are believed to
be most likely to be the targets of an attack on the system. Targeted processes run in their own
SELinux domain, known as a confined domain, which restricts access to files that an attacker
could exploit. If SELinux detects that a targeted process is trying to access resources outside
the confined domain, it denies access to those resources and logs the denial. Only specific
services run in confined domains. Examples are services that listen on a network for client
requests, such as httpd, named, and sshd, and processes that run as root to perform tasks on
behalf of users, such as passwd. Other processes, including most user processes, run in an
unconfined domain where only DAC rules apply. If an attack compromises an unconfined
process, SELinux does not prevent access to system resources and data.

Multilevel Security (MLS) Policy applies access controls to multiple levels of processes with
each level having different rules for user access. Users cannot obtain access to information if
they do not have the correct authorization to run a process at a specific level. In SELinux, MLS
implements the Bell–LaPadula (BLP) model for system security, which applies labels to files,
processes and other system objects to control the flow of information between security
levels. In a typical implementation, the labels for security levels might range from the most
secure, top secret, through secret, and classified, to the least secure, unclassified. For
example, under MLS, you might configure a program labelled secret to be able to write to a
file that is labelled top secret, but not to be able to read from it. Similarly, you would permit
the same program to read from and write to a file labelled secret, but only to read classified
or unclassified files. As a result, information that passes through the program can flow
upwards through the hierarchy of security levels, but not downwards.

4.3 Working with SELinux

Open this web document:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html-single/security-
enhanced_linux/index

Or use the attached PDF format of the same document.

The experiments are in sections 4, 5.5, and 5.11.

6
4.4 Useful References:

https://www.youtube.com/watch?v=tXNr3gOgrn8
https://www.youtube.com/watch?v=O8YQVpneH5w
https://www.youtube.com/watch?v=ZW80ASpXYiQ
https://www.youtube.com/watch?v=rJrsUpSX9P0&list=PLbPTI55vtiGuege6PrJpnvuP9y_
MKyio7