oss coursework assignment 2014_2015

CYBER SECURITY AND NETWORKS

STEPHEN KERR

S1432672

Contents

INTRODUCTION.....................................................................................................................................2

LINUX SECURITY.....................................................................................................................................3

WHY DAC ISN'T ALL THAT..................................................................................................................3

WHAT IS SELINUX?.............................................................................................................................4

MODES..............................................................................................................................................5

PUTTING LABELS INTO CONTEXT.......................................................................................................5

ALL IN THE POLICY.............................................................................................................................6

APACHE SERVER DIRECTORY CONFIGURATION AND SHELL SCRIPT.......................................................8

SHOWING THE MODES......................................................................................................................8

SELINUX IN ACTION...........................................................................................................................9

CHANGING THE LABELS...................................................................................................................10

STICKING TO THE SCRIPT.................................................................................................................11

CONCLUSIONS.....................................................................................................................................15

1

INTRODUCTION

One of the most important aspects of an operating system is the security of all the files within it. Linux is no different in that regard. As far as the average Linux user is concerned, as long as only authorised users have access to the relevant resources then the system should therefore be secure. To this end, most users are only concerned about read, write and execute permissions. While it is a good idea to ensure that these permissions are correct, this alone isn’t enough to secure the integrity of files within the system. Permissions grant access to resources based on if the user is the owner or belongs to a particular group. It won’t stop the user performing potentially dangerous actions such as making the resource available for the world to see or stop a malicious program accessing resources. This is a rather serious problem. However, there is a form of security called SELinux that can be used in conjunction to permissions that will allow fine-grained control over how access is granted to all resources in the system. This allows any actions that put the system at risk to be stopped.

This report will offer a comprehensive overview of SELinux, describing the various mechanics behind it such as the importance of labelling files, the security policies that it’s based on and the different modes that it uses. In addition to this, lab work will be performed to demonstrate SELinux operating in a real-life scenario. This will offer a deeper understanding and underline the importance of SELinux.

2

LINUX SECURITY

WHY DAC ISN'T ALL THAT

Discretionary Access Control (DAC) is a form of security in which the Linux system determines if a user or process is permitted to access a resource (like a file or directory). This method of security will grant access to resources depending on what category a user belongs to. There are three different categories: ownership, group membership and all other system users. Every resource on the system has read, write and execute permissions associated with them which determine what a user belonging to a certain category can do. The permissions are arranged as follows:

rwxrwxrwxowner -group -other

One thing to note is that the meaning of read, write and execute differs depending on whether the resource is a file or directory.

For files:

r read the contents of a file

w modify the contents of a file

x file is executable

For directories:

r can look at contents of directory

w can move contents to and from directory

x can change location into directory

3

The above example shows the permissions of a file called “Stephen”. It has the owner permissions set to read and write, the group permissions set to read and the other permissions set to read.

There are also Access Control Lists (ACLs) which grants a user access to resources even if they don't have permissions assigned to them.

In short, DAC is designed so that only authorised users or processes can access certain resources. However, there is a critical flaw in this. DAC only takes into account user identity and ownership. It has no concept of dangerous actions that a user may perform on a resource, if a program that is accessing a file is trustworthy or even how sensitive the data in a file is. A user who has the relevant permissions can essentially do as they please with a file, including changing the permissions on it so everyone can access it. Furthermore, a process started by a user inherits the permissions of that user. So if a user executes a malicious program in their home directory, then that program can access (and therefore read) all the files that the user can. This poses a significant security risk (especially if the user is root). However, there is an answer to this. Security-Enhanced Linux (SELinux) is a security tool that can be used in addition to DAC which can resolve these issues and maintain the integrity of the file system.

WHAT IS SELINUX?

SELinux is a form of Mandatory Access Control (MAC) that operates under the principal of least privilege. The idea behind the principal of least privilege is that a process should only get enough access in order to function properly and no more. As previously stated, a user could execute a malicious program in their home directory, therefore giving the program access to all the files and directories that the user can access. However with SELinux the program would be denied access to files that aren't required for it to function. This is due to a system-wide security-policy that is set which allows fine-grained control over all aspects of the Linux system including users, programs, files, processes as well as any other elements in the system.

SELinux is a very powerful tool however it should not be considered a direct replacement for firewalls or antivirus. It is designed to complement already-implemented security measures in order to provide defense in depth.

4

MODES

In SELinux there are three different modes that can be used, depending on the intentions that the administrator may have. These modes are:

Enforcing: The SELinux policy is used and access to resources is denied unless the policy states otherwise. This is the desired setting, however for debugging purposes it may be necessary to switch to another mode.

Permissive: While everything is checked against the policy, this time access is NOT denied. Anything that would have been denied in enforcing mode is logged to the Access Vector Cache (AVG). If there are problems with enforcing mode, then permissive mode would allow troubleshooting to be performed to establish the cause of the issue without having to fully disable SELinux.

Disabled: This mode turns off SELinux. This is the least desirable mode as Linux security would fall back to using DAC rules exclusively. In addition to this, any newly created files would not be labelled (more on labelling later) and this would cause unnecessary headaches for any administrator tasked with labelling the files. Unfortunately some believe that SELinux is “too hard” and just disable it out the box which only causes problem further down the line. Permissive mode is the preferred option to this as the labelling function is retained.

PUTTING LABELS INTO CONTEXT

Under SELinux, everything is grouped into two different categories: objects and subjects. Anything that is static (like devices, files and directories) is classified as an object whereas anything that is dynamic (such as processes) is classed as a subject. SELinux allows control over how subjects interact with objects and how subjects interact with each other. This is done through labelling.

Labelling allows SELinux to classify objects and subjects into certain categories. Rules are then enforced which determines what a subject may or may not access. A label (or context) is a string that consists of three or four words separated by a semi-colon. Each word in this string specifies a different field. The fields are User, Role, Type and Level.

Below is a brief description of each field that makes up a label:

5

User: A normal user can be mapped to be a SELinux user. A SELinux user can have many roles and within these roles they would be able to access various domains. This field isn’t too important in the targeted policy however in the strict policy it becomes more pertinent (more on policies later). The user field normally has three different users which are user_u (the default SELinux user), system_u (processes started during bootup) and root (when one is logged in as root).

Role: Roles are the middlemen between users and types. The role that a SELinux user is assigned determines the domains and types a user can access. This is described as Roles Based Access Control (RBAC). Again, this isn’t relevant to the targeted policy but is more important in the strict policy. On a file the role field is shown as object_r and for process they appear mostly as system_r or sysadm_r.

Type: This is considered the most important context field. It defines a domain for processes and a type for files. The security policy determines how the types interact with each other (for example if a domain can access another domain, or if a domain can access a type). Most security policies are based on what types can access each other. The type field can be shown in various forms, but always ends with a _t.

Level: This field is pertinent to Multi-Category Security (MCS). It allows for the creation of categories and then assigning users to those categories. This allows users that belong to specific departments to access the files that are relevant to them. This field can show up as s:0-s15:c1,c2. This is an optional field.

This example shows the context for the file “Stephen”. It has the user field as unconfined_u, the role field as object_r, the type field as admin_home_t and finally the level field being s0.

ALL IN THE POLICY

There are two main types of policies that SELinux abides by. They are:

6

Targeted: The targeted policy allows for certain domains to be confined while everything else runs in an unconfined domain. The unconfined domains use standard DAC while the confined domains can only access certain objects or subjects. This means that if a domain has been exploited then only limited damage can be done. This is the preferred security policy as it allows normal operation of the system while preventing domains accessing data not required for them to function.

Strict: The strict policy is the opposite of the targeted policy. All subjects are put into their own specific domain, and access is denied unless the policy states the domain is allowed access to other domains or types. This is only used in certain circumstances (if the data is the system is highly confidential, like a government database) as it can be quite complex. An example of the strict policy is Multilevel Security (MLS).

7

APACHE SERVER DIRECTORY CONFIGURATION AND SHELL SCRIPT

Now that we have discussed the concepts and mechanics behind SELinux, we can now put this into practice. The following lab work will demonstrate the power of SELinux and how the modifications of labels can allows domains to access types that are usually outside of their jurisdiction.

SHOWING THE MODES

Firstly, we want to establish the mode that SELinux is operating under. This is done by using the sestatus command.

The setenforce command can be used to change the mode to either enforcing or permissive. Appending enforcing or 1 after the setenforce command will set the mode to enforcing whereas appending 0 after the setenforce command will set the mode to permissive. However, these changes are only temporary. The changes can be made permanent by modifying the /etc/selinux/config file. SELinux can also be disabled this way. The output of the /etc/selinux/config file is below.

8

By appending SELINUX= with enforcing, permissive or disabled, the mode can be changed permanently. Furthermore, we can change the policy type to targeted or mls by having SELINUXTYPE=targeted or mls. For the purpose of this demonstration we will be using enforcing mode and the targeted policy.

SELINUX IN ACTION

Linux uses the http daemon (httpd) to allow webpages to be served from the Apache server. Httpd is disabled by default but can be enabled using the service httpd start command. The default directory from which the Apache server hosts webpages is /var/www/html. Under the targeted policy, SELinux won’t allow files to be served from any other directory than /var/www/html. To demonstrate this, the /var/test directory has been created. This directory will have a symbolic link created in /var/www/html which links /var/test to /var/www/html. By doing this, we can attempt to serve files from the /var/test directory.

9

The file xmas has been created and put into /var/test. We can attempt to access this file through Firefox by typing into the URL http://localhost/test/xmas .

As we can see, access has been denied to the xmas file in Firefox. This is because the label type in /var/test is var_t. The policy only allows objects with the label type httpd_sys_content_t to be accessed by httpd.

CHANGING THE LABELS

So, how can we allow httpd to access files in /var/test? We change the label type. This is done using the chcon command which allows labels to be changed for objects and subjects.

10

The directory /var/test now has the label type httpd_sys_content_t. This will now allow any files to be served from /var/test. We use the –R switch to allow a recursive change (so all files and directories within /var/test change as well) and we use the –t switch to indicate that it is the type that we are changing. The user and role labels can also be changed by using the switches –u or –r respectfully.

Now, if we retrieve the xmas file in Firefox we are successful.

Obviously in a real life scenario we wouldn’t want to change labels in this manner. This example is just to demonstrate the importance of labels and the role they play in how subjects access objects.

STICKING TO THE SCRIPT

When testing SELinux, it is desirable to create a script that does all the testing for you. Using the example with httpd, we would have to use a web browser and type in a URL every time to see if the file can be served. By creating a script, we can put in only the name of the file as a parameter to be tested and then output to the console if the file was served successfully or not. This will allow more efficient testing to take place.

One way of testing if a file can be served from a directory is by using the wget command. Wget downloads files from a server and saves the contents. We can use this to test if a file from /var/test can be served.

A script called http.sh has been created in the home directory. The file summer has been created for the purpose of this exercise. The following shows the contents of the script as well as comments that describe what each command in the script does.

11

Before using this script, we want to see the label type for /var/test.

The label type is httpd_sys_content_t. This therefore will allow wget to download files located in /var/test. We will use the script to copy summer to /var/test and retrieve it. We will also try entering a file that doesn’t exist (the winter file) to demonstrate what would happen if we tried to copy something that isn’t a file.

12

The script has worked successfully. We can see that if the parameter is a file then we receive the success message. We also can see that if it is not a file, then an error message will indicate this.

What if we changed the label type for /var/test back to its default type? We can use the restorecon command. This will change a file or directory back to its default context.

Now if we execute the script again…

13

We now get the message that we couldn’t retrieve the file. This is due to the label being changed back to one that cannot be accessed by the httpd daemon.

14

CONCLUSIONS

SELinux can be an incredibly powerful tool. Every little element of the system can be modified to determine exactly who can access what. This is an essential function to have as many subjects can be exploited. Unfortunately, subjects aren’t limited to only performing the actions that they are designed for. They can also read sensitive data in file systems (even if there is no need for them to do so.). SELinux can ensure that a subject can only access specified objects, thus preventing a subject accessing files not required for it to perform (like files with sensitive data on a user’s home directory). An example of this would be in the lab work where the httpd daemon was prevented from accessing a directory which didn’t have the httpd_sys_content_t label. Just as importantly, it will not interfere with the end users experience. Users can still access resources like normal without being blocked off at every turn and corner, which is important for productivity.

As daunting as SELinux may initially appear to be, it is in actuality simpler to configure than first appears. SELinux can become quite convoluted in strict policies due to the various configuration settings that have to be modified. However, in the targeted policy as long as the user is aware of what domains can access what types then SELinux can be somewhat simplified. For the majority of the time, the targeted policy is mostly used. Therefore an administrator doesn’t need to have too much in-depth knowledge to configure SELinux. Unfortunately SELinux is sometimes disabled due to the misconception that it is too hard to configure. However the previous lab demonstration has proved that very little configuration actually has to be done in order to set SELinux up properly, just some knowledge of resource context and modes.

It is this author’s opinion that SELinux shouldn’t be seen as an irritant, but a necessity. While DAC is an essential security mechanism, the fact that permissions are set at a user’s discretion is poor security practice. With SELinux, all aspects of access can be determined by an administrator who can set a security policy that is employed uniformly throughout the entire system. This ensures that it is only an administrator that can determine access as well as limiting the access of exploited subjects. Hopefully the misconception of the difficulty of SELinux will fade over time as it is used more.

15