PREVENTING EXPLOITS WITH SECURITY ENHANCED LINUX

Transcription

1 PREVENTING EXPLOITS WITH SECURITY ENHANCED LINUX Final Report 12/10/09 Mike Detwiler UMBC Student CMSC Course 426 Baltimore, MD Peter Coddington UMBC Student CMSC Course 626 Baltimore, MD ABSTRACT Single user root access for operating systems is a security risk. This paper will explain how the root access can be split into two security policies one is in secure mode the other is administrative mode which is the traditional root access that currently allows the full access we see today. In this fashion one user can have only operational read only access (Secure Mode) while the other user can have full access for configuration changes (Administration Mode). Dividing policies and associated user access into two classes, helps mitigate risk at the root level for UNIX/Linux. 1. Introduction Traditionally, operating systems have an administrative account with elevated privileges for the purpose of system administration. On UNIX/Linux systems, this system administration account is given the username of root. Because the root account has unlimited privileges, it poses a single point of failure security risk. This is a single point of failure because one level of access and a single person has access to the entire root. An attacker gaining control of this account will have unfettered access to the system allowing him to exploit it many ways. A common exploit is to modify the system binary (executable) files for the attacker's malicious purposes. One possible means of preventing such attacks would be to eliminate the system administrator account. This would prevent any user from modifying the system maliciously. However, this would also prevent legitimate system modifications, such as software upgrades and other administrative tasks. Finding the proper balance between system security and system flexibility is the challenge. We propose a solution to this problem that creates two separate security policies thus creating two levels of access to the root. The first level will be run during normal operation of the system. This Secure Mode will use Security Enhanced Linux (SELinux) policies to enforce a system in which no user account has system administration privileges. Therefore, no user will be able to modify the system binary files. The second level or Administration Mode will be used only for the purpose of system administration tasks. When administration tasks such as software update are required, an administrator will boot into this kernel and perform the software upgrade. 2. Related Work Much of the previous work in this area has been centered on Security Enhanced Linux (SELinux). SELinux provided the necessary platform to create the additional security policy for the Secure Mode. SELinux evolved from a research project of the National Information Assurance Research

2 Laboratory of the National Security Agency (NSA) in conjunction with Secure Computing Corporation (SCC).[2] The goal of the project was to develop a strong, flexible mandatory access control architecture based on type enforcement. The NSA and SCC developed two prototypes of the architecture. They then worked with the University of Utah's Flux research group to transfer the architecture to the Fluke research operating system. Along the way, the architecture was enhanced to provide better support for dynamic security policies. This enhanced architecture was named Flask.[1,2,5] Because there was no widely used implementation of the Flask architecture, the NSA proposed integrating the architecture into the Linux operating system to so that it could benefit from exposure to a larger developer and user community. Linus Torvalds, the creator of the Linux kernel, did not want to endorse the NSA architecture as the only security system for Linux[5]. He noted that there were several other security projects in existence, and he did not want to favor one over the other. So he charged the security community with developing a flexible security framework for the kernel that would allow security modules to be loaded into the kernel. These modules would make decisions about mandatory access control (MAC).[2] After two years of effort and contributions from members of the security community, the result was Linux Security Modules (LSM)[5]. The NSA architecture was written as a Linux Security Modules and thus was born SELinux. Since that time, the architecture has been implemented in other operating systems, such as Solaris and BSD. Along with the Linux Security Module, NSA provided a reference security policy implementation.[4] The maintenance of this reference policy has been taken up by Tresys Technology. Tresys saw the need for a SELinux reference policy that was modular, extensible and could easily be adapted to the security goals of multiple projects. In addition, it was necessary to engage the SELinux community to ensure that the resulting technology could be transferred to Linux distributions and commercial Linux products. They developed a modular, comprehensive, welldocumented, and secure SELinux security policy[4]. It is now the basis for the standard SELinux security policy shipped by vendors such as Fedora/Redhat, Gentoo, and others. Each Linux distribution vendor takes reference policy and modifies it for their needs. The security policy shipped with Fedora/Redhat was the basis point for our research. 3. Model Threat Description The model/threat deals with the current access control methods which carry too much risk. The risk is created when the root user access is not divided into some additional levels of privileges. This research project divides access into two levels instead of just one level for all users. By creating two policies and therefore two levels of privileges, risk is mitigated with less users needing full administrative access to the root level. Many users can operate, for example, out on a network in only the secure mode this limits the access that others can get or even need to the root directory [1]. Many tasks do not need full root access with write access read access is enough. To mitigate this risk, dividing the risk and separating the development and software installation of updates to the Kernel and OS into one compartment and the installation of operational OS updates onto the current operational Kernel into another compartment makes sense. Specifically, this paper will propose and prove that creating a second kernel (Secure Kernel) from the existing kernel (Administrative Kernel) allows for separation and mitigates risk. The Administrative Kernel is accessible only to a certain set of trusted system administrators for the purpose of system installation and upgrade. The Secure Kernel will run during normal system operation.

3 4. ARCHITECTURE/PROPOSAL METHOD SELinux is an implementation of a MAC policy mechanism in the Linux kernel.[3] It further controls which operations are allowed after standard discretionary access controls are checked. It enforces rules on files and processes, and on their actions, based on a defined policy. Like other security solutions, in SELinux, files, including directories and devices, are referred to as objects. Processes, such as a user running a command, are referred to as subjects. The subject (or user) accesses the SELinux security Server (see diagram below) with a request. Then the SELinux server checks first the cache to see if that subject and the requested object have been accessed before if its not in the AVC (Access Vector Cache)[2,5] with approved access, the SELinux Security Server checks the SELinux for access control decision. If the subject-object access is within the accessible mode for either the secure or administrative mode, then the AVC is updated in the SELinux Security Server [1]. If the subject s requested object access is not allowed then an error message is issued. information is used to make access control decisions. In reference policy, the system binary directories and files are labeled with the type bin_t, while system library directories and files are labeled with the type lib_t. Our research approach was to modify SELinux reference policy to eliminate the ability of any user (including root) to modify system binary/library files. This is done by eliminating the privilege of managing any of the files labeled with these types from all users.[3] Our architecture will be based of the SELinux implementation that exists in the Linux kernel version as patched by Fedora, a Linux distribution vendor. Our security policy will be based off Fedora's Multi-Level Security policy[3] for SELinux, version As mentioned, Fedora's policy is based off of the reference policy maintained by Tresys. This policy can be downloaded from the Tresys git repository found at After analyzing the policy, we removed the privilege of the system administrator (sysadm_u) and security administrator (secadm_u) to manage files and directories labeled with type bin_t and lib_t. Since the security administrator normally has privileges to relabel files with a different type, these privileges must be stripped to eliminate a security hole. The unified diff of our changes to reference policy can be seen below. Policies[6]: Processes and files are labeled with an SELinux context that contains additional information, such as an SELinux user, role, type, and security level. When SELinux policy is enforced, all of this diff --git a/policy/modules/roles/secadm.te b/policy/modules/roles/secadm.te index ed4f9fd..b6ea3ce a/policy/modules/roles/secadm.te ,7 mls_file_upgrade(secadm_t) mls_file_downgrade(secadm_t) auth_role(secadm_r, secadm_t) -auth_relabel_all_files_except_shadow(secadm_t) +#auth_relabel_all_files_except_shadow(secadm_t)

4 +auth_relabel_all_files_except_shadow(secadm_t, { -bin_t -lib_t }) auth_relabel_shadow(secadm_t) init_exec(secadm_t) diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te index 2ed3c67..27cb0b a/policy/modules/roles/sysadm.te ,9 optional_policy(` rpc_domtrans_nfsd(sysadm_t) ') -optional_policy(` - rpm_run(sysadm_t, sysadm_r) -') +##optional_policy(` +# rpm_run(sysadm_t, sysadm_r) +#') optional_policy(` rssh_role(sysadm_r, sysadm_t) diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if index f209ccf..a59c9fa a/policy/modules/system/userdomain.if ,9 template(`userdom_admin_user_template',` auth_getattr_shadow($1_t) # Manage almost all files - auth_manage_all_files_except_shadow($1_t ) + # auth_manage_all_files_except_shadow($1_t) + auth_manage_all_files_except_shadow($1_t,-bin_t -lib_t) # Relabel almost all files - auth_relabel_all_files_except_shadow($1_t) + # auth_relabel_all_files_except_shadow($1_t) + auth_relabel_all_files_except_shadow($1_t,- bin_t -lib_t) -1224,7 template(`userdom_security_admin_template',` selinux_set_all_booleans($1) selinux_set_parameters($1) - auth_relabel_all_files_except_shadow($1) + # auth_relabel_all_files_except_shadow($1) + auth_relabel_all_files_except_shadow($1,- bin_t -lib_t) auth_relabel_shadow($1) init_exec($1) After making these changes, the next step was to apply this patch to the Fedora selinux-policy package. This involved downloading the source rpm from Fedora, installing the rpm source, applying our patch, and then rebuilding the rpms. Once this was complete, we could install our patched policy on our test server. A reboot is necessary to allow the entire filesystem to be labeled according to the new security policy. Once this policy is fleshed out, the secure kernel will be safe from malicious attacks. Then next step will be to modify the kernel to determine which policy should be loaded at boot time. This will require further investigation of the kernel source code and libselinux, to implement a decision of which policy to load at runtime. 5. Security Analysis/Experiments The results of our secure policy enforcement were encouraging. After our policy had been loaded by the kernel, and the filesystem relabel, we began experimenting with our new system. The first test was to see if the root user could write to system binary or library directories or files. The images and their descriptions below demonstrate our results. The first image can be found at the end of this paper and is described as follows. The id command shows that the Linux user detwiler is logged in as the

5 SELinux user staff_u, with the staff_r role in the staff_t domain. It also shows the MLS range encompasses all levels of security (SystemLow- SystemHigh). The next command, semanage, cannot be run by the staff_r role, so it must be prefaced with the sudo command which has built in role transition which will be discussed shortly. The semanage user -l command lists summary information about the SELinux users defined in the currently loaded policy. The staff_u user has the following roles associated with it. auditadm_r: audit administrator staff_r: general staff role secadm_r: security administrator sysadm_r: system administrator system_r: role for system services/processes The staff_u user is allowed to transition into the above roles in order to perform tasks that are privileges of the corresponding role. The final command shows the point in the sudo configuration file where the Linux user detwiler is transitioned automatically into the sysadm_r role in the sysadm_t domain (type) when executing the sudo command. This setting can be overridden with command line options to the sudo command as we shall see shortly. The sestatus command shows that SELinux is enabled and in enforcing mode. The policy type is our modified Multi-Level Security (MLS) policy. $ ls -dz /bin This command lists the security context of one of the system binary directories. It shows that its type is bin_t. We first try to create a file named foo in the /bin directory by using the sudo command to transition to the sysadm_r role in the sysadm_t domain to execute the touch /bin/foo command. Standard MLS policy would normally give a user in this role permission to create this file, however, the secure policy prevents sysadm_r from writing to this directory. Next we use the sudo command to enter into a root shell. We again attempt to write a file to the /bin directory, and once again we find that even root does not have sufficient privileges. Our next step will to be to test a system library directory in the same way. Moving on, our next step is to exercise our secure policy. We start by attempting to write a new file to the /bin directory as shown in the image below. We see that the /lib system library directory is labeled lib_t. Because our policy has taken away privileges to write to this directory, permission is denied. Finally, root is also denied permission to write to this directory.

6 Our initial effort to secure reference policy assumed that removing the privilege to manage directories and files labeled with bin_t or lib_t would be sufficient to prevent installation of new, potentially malicious software. However, as we discovered, the program that installs software, rpm, runs in a privileged domain and was therefore still able to write to these directories, despite our policy changes. Finally, we need to test our policy that prevents SELinux context relabeling. Going back to the drawing board, we found the location in reference policy where permission was granted to the sysadm_r role to run rpm. We removed this privilege and reloaded our policy. We attempt to change the security type of /bin from bin_t to user_home_dir_t, the type of our home directory. The chcon command would normally allow a system or security administrator to do this depending on the type of policy. Our first attempt fails. Recall that the sudo configuration file transitions us into the sysadm_r role in the sysadm_t domain by default. We must override this setting with command line options to sudo to ensure that the security administrator is also unable to perform this command. We tell sudo to transition to the secadm_r role in the secadm_t domain before executing the chcon command. Alas, permission is denied for the secadm_r role to change security labels. 6.REMEDIATION In the image above we have asked yum, a command line tool that wraps around rpm, to install some new software. We answer yes when prompted. As we can see, the software download proceeds without incident, but when yum tries to invoke rpm to install the software, the installation fails. We have successfully blocked software installation and modifications. The creation of a second policy means that any need for configuration updates requires the normal operation of the system in secure mode for most of the users, will need to shut down the system to put in place the policy for the administration mode for access to the write only binary files. System shutdown between policy changes between Secure and Administrative mode still needed. Additionally, the task of switching between policies is still manual. Future work would need to look at means of automating that switch.

7 7. CONCLUSION SELinux allows for creating a separation of users for the root. Separation is one of the best means to help with security. By creating two policies where there was previously only one policy for one user makes access to the root more secure. Dividing the user population s access to the root into two groups, helps mitigate risk. 8. FUTURE WORK Future work would allow automatically work on three items: 1. Policy loads for SELinux would happen automatically on boot of the computer. The computer on boot would decide which policy Secure Mode or Administration Mode would load. Changing between policies can be difficult and would take effort to create a system that could do so [1]. 2. Secure Mode Policy could have some ore limits on privilege. The limits could be refined to insure further security. For example, certain libraries/binaries could be further limited through policy to restrict more access to the root directory. 3. This system can be further tested in a more robust environment. This project has created a system that has not been tested in a more robust operational/test environment. REFERENCES Gregory, Machon and Loscocco, Peter. Using the Flask security Architecture to facilitate Risk adaptable access controls. NSA. Loscocco, Peter and Smalley, Stephen. Integrating Flexible support for Security Policies into the Linux Operating System. NSA. Loscocco, Peter A. and Smalley, Stephen D. Meeting Critical Security Objectives with Security-Enhanced Linux. NSA. PeBenito, Christopher and Mayer, Frank and MacMillan, Karl. Reference Policy for Security Enhanced Linux. Tresys Technology. Smalley, Stephen, and Vance, Chris and Salamon, Wayne. Implementing SELinux as a Linux Security Model. NSA. Tresys Technology Open Source Software SELinux Reference Policy.