Access Control. SELinux. Mestrado Integrado em Engenharia Informática e Computação. Computer Systems Security

Transcription

1 Access Control SELinux Mestrado Integrado em Engenharia Informática e Computação Computer Systems Security João Carlos Eusébio Almeida - up João Gabriel Marques Costa - up May 17,

2 Contents 1 Introduction Access Control Security-Enhanced Linux How SELinux works Five golden principles of security The Decision Making Process Getting into SELinux Mandatory Access Control (MAC) Security Context Type Enforcement (TE) Role-Based Access Control (RBAC) Multi-Level Security (MLS) Multi-Category Security (MCS) Security Policy Modes Permissive Domains Booleans Utilities List of common problems Wrong Subject Context Wrong Object Context Right Subject and Object Context but No Access How to install SELinux in a Debian System 11 4 Example Use Cases MCS Usage Conclusion 15 2

3 1 Introduction 1.1 Access Control Access control is a security technique that can be used to regulate who or what can view or use resources in a computing environment. There are two main types of access control: physical and logical. Physical access control limits access to campuses, buildings, rooms and physical IT assets. Logical access limits connections to computer networks, system files and data. The three main models of access control are: Discretionary Access Control (DAC): defines the basic access controls for objects in a filesystem. This is the typical access control provided by file permissions, sharing, etc. Such access is generally at the discretion of the owner of the object (file, directory, device, etc.). DAC provides a means of restricting access to objects based on the identity of the users or groups (subjects) that try to access those objects. Depending on a subject s access permissions, they may also be able to pass permissions to other subjects. Mandatory Access Control (MAC): is a security mechanism that restricts the level of control that users (subjects) have over the objects that they create. Unlike in a DAC implementation, where users have full control over their own files, directories, etc., MAC adds additional labels, or categories, to all file system objects. Users and processes must have the appropriate access to these categories before they can interact with objects. This is talked more in depth in the respective [2.3.1] section of the document. Role-based Access Control (RBAC): is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. Roles are defined according to job competency, authority, and responsibility within the enterprise. When properly implemented, RBAC enables users to carry out a wide range of authorized tasks by dynamically regulating their actions according to flexible functions, relationships, and constraints. This is in contrast to conventional methods of access control, which grant or revoke user access on a rigid, object-by-object basis. 1.2 Security-Enhanced Linux Security-Enhanced Linux (SELinux) is an implementation of MAC on Linux and an incredibly powerful tool for securing Linux servers. It has a reputation for being difficult to configure and, as a result, many system administrators simply choose to turn it off. Its architecture strives to separate enforcement of security decisions from the security policy itself and streamlines the volume of software charged with security policy enforcement. It provides an enhanced mechanism to enforce the separation of information based on confidentiality and integrity requirements, which allows threats of tampering and bypassing of application security mechanisms to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications. For the purpose of this project, the group has decided to thoroughly study the implementation and architecture of SELinux as well as setup a number of use cases and tests. 3

4 2 How SELinux works 2.1 Five golden principles of security 1. Know your System: know what it runs on, what its network is like, traffic, etc. 2. Principle of Least Privilege: Don t give users more privileges than they need to do their job. 3. Defense in Depth: Don t just do one thing to protect your system. 4. Protection is key but detection is a must. 5. Know your enemy: what tools he uses, means of attack, etc. With SELinux it is possible to achieve these principles. Most operating system use Discretionary Access Control (DAC) to control how processes interact with files and the way processes interact with each other. However, it is not without issues. Allowing users to control object access permissions has the side-effect of opening the system up to Trojan horse susceptibility. Additionally, maintenance of the system and verification of security principles is extremely difficult for DAC systems because users control access rights to owned objects. The so-called Safety Problem": the lack of constraints on copy privileges, is another liability inherent to DAC. This lack of constraints on copying info from one file to another makes it difficult to maintain safety policies and to verify that those safety policies are not compromised. SELinux adds additional control beyond what is offered with traditional DAC. Processes and resources have security properties associated with them and the security policy in the kernel is flexible and easily changeable. A general purpose MAC architecture needs the ability to enforce an administratively-set security policy over all processes and files in the system, basing decisions on labels containing a variety of security-relevant information. 2.2 The Decision Making Process When a subject, (for example, an application), attempts to access an object (for example, a file), the policy enforcement server in the kernel checks the Access Vector Cache (AVC), where subject and object permissions are cached. If a decision cannot be made based on data in the AVC, the request continues to the security server, which looks up the security context of the application and the file in a database. Permission is then granted or denied, with an avc: denied message detailed in /var/log/messages if permission is denied. 2.3 Getting into SELinux Mandatory Access Control (MAC) Figure 1: Decision making process of SELinux Mandatory Access Control (MAC) is a type of access control in which the operating system is used to constrain a user or process (the subject) from accessing or performing an operation on an object (such as a file, disk, memory, socket etc.). Each of the subjects and objects have a set of security 4

5 attributes that can be interrogated by the operating system to check if the requested operation can be performed or not. For SELinux the: Subjects are processes. Objects are system resources such as files, sockets, pipes, network interfaces etc. that are accessed via processes (subjects). Security attributes are the security context [2.3.2]. Security Server within the Linux kernel authorizes access (or not) using the security policy [2.3.7] (or policy) that describes rules that must be enforced. Note that the subject (and therefore the user) cannot decide to bypass the policy rules being enforced by the MAC policy with SELinux enabled. Contrast this to standard Linux Discretionary Access Control (DAC), which also governs the ability of subjects to access objects, however it allows users to make policy decisions. SELinux supports two forms of MAC: Type Enforcement (TE) [2.3.3]: Where processes run in domains and the actions on objects are controlled by the policy. This is the implementation used for general purpose MAC within SELinux along with Role Based Access Control (RBAC) [2.3.4]. Multi-Level Security (MLS) [2.3.5]: This is an implementation based on the Bell-La Padula (BLP), and used by organizations where different levels of access are required so that restricted information is separated from classified information to maintain confidentiality. This allows enforcement rules such as "no write down" and "no read up" to be implemented in a policy by extending the security context to include security ranges or levels [2.3.2] Security Context A security context is a string made up of 3 or 4 attributes which are separated by ":". Those attributes are of type: user:role:type[:range] : user: an identity known to the policy that is authorized for a specific set of roles, and for a specific MLS/MCS range. Each Linux user is mapped to an SELinux user via SELinux policy. This allows Linux users to inherit the restrictions placed on SELinux users. Every process ran during an user s session uses the security context mapped to it s SELinux user identity. role: part of the Role-Based Access Control (RBAC) [2.3.4] security model in SELinux. SELinux users are authorized for roles, and roles are authorized for domains. type: is an attribute of Type Enforcement (TE) [2.3.3]. It defines a domain for processes, and a type for files. SELinux policy rules define how types can access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. range: is an attribute of MLS and MCS. An MLS range is a pair of levels, written as lowlevelhighlevel if the levels differ, or lowlevel if the levels are identical. A set of category labels can also be used if they are defined in /etc/selinux/<selinuxtype>/setrans.conf. Figure 2: Example of a process security context 5

6 2.3.3 Type Enforcement (TE) SELinux makes use of a specific style of type enforcement to enforce mandatory access control. For SELinux it means that all subjects and objects have a type identifier associated to them that can then be used to enforce rules laid down by policy. The SELinux type identifier is used in the majority of SELinux language statements and rules used to build a policy that will, when loaded into the security server, enforce policy via the object managers Constraints It is possible to add constraints on users, roles, types and MLS ranges, for example within a TE environment, the way that subjects are allowed to access an object is via a TE allow rule, for example: allow unconfined_t ext_gateway_t : process transition; This states that a process running in the unconfined_t domain has permission to transition a process to the ext_gateway_t domain. However it could be that the policy writer wants to constrain this further and state that this can only happen if the role of the source domain is the same as the role of the target domain. To achieve this a constraint can be imposed using a constrain statement: constrain process transition ( r1 == r2 ); This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules) Role-Based Access Control (RBAC) To further control access to TE domains SELinux makes use of role-based access control (RBAC). This feature allows SELinux users to be associated to one or more roles, where each role is then associated to one or more domain types as shown in figure 3. The SELinux role name is the second component of a security context. It is possible to add constraints and bounds on roles as seen above. Figure 3: RBAC in SELinux Multi-Level Security (MLS) As previously stated [2.3.1][2.3.2], SELinux supports MLS/MCS by the use of the 4th attribute (range) in the security context. The implementation conforms to the Bell-La Padula BLP model in that a process (running at the "Secret" level) can read/write at their current level but only read down levels or write up levels (figure 4). This ensures confidentiality as the process can copy a file up to the secret level, but can never re-read that content unless the process "steps up to that 6

7 level", also the process cannot write files to the lower levels as confidential information would then drift downwards. Figure 4: Data Flows using MLS System MLS access rules are always combined with conventional access permissions (file permissions). For example, if a user with a security level of "Secret" uses Discretionary Access Control (DAC) to block access to a file by other users, this also blocks access by users with a security level of "Top Secret". A higher security clearance does not automatically give permission to arbitrarily browse a file system. Users with top-level clearances do not automatically acquire administrative rights on multi-level systems. While they may have access to all information on the computer, this is different from having administrative rights Multi-Category Security (MCS) Mult-Category Security (MCS) is an optional addition in SELinux that allows users to add categories to subjects and objects (in the range attribute of the security context). It is an extension on top of the current MLS implementation, although it does not follow the BLP model, and basically adds the additional constraint to the access check requiring that the categories that the process has must be a of the categories of the files it is accessing. Note that categories are defined as a set and not as a range, meaning that access is granted if the object s categories is a subset of the subject s categories (objects without a category can be accessed by anyone, provided they pass all previous access checks) Security Policy Policy is the set of rules that guide the SELinux security engine. It defines types for file objects and domains for processes, uses roles to limit the domains that can be entered, and has user identities to specify the roles that can be attained. Usually operating systems that come with SELinux pre-installed already provide a custom tailored policy like, for example, Red Hat Linux and CentOS. However, due to the modular nature of SELinux, it is extremely easy to customize or extend the current policy Modes There are 3 different modes of operation in SELinux: Enforcing: This tells the system to run with SELinux enforcing the currently active policy, watching all system access checks, stopping all denied accesses and logging all AVC violations. 7

8 Permissive: Functions the same way as in enforcing mode, except that it does not stop denied accesses (but still logs them). Disabled: The SELinux infrastructure is not enabled, therefore no policy can be loaded (or enforced) Permissive Domains SELinux lets the administrator change a single process type (domain) to be permissive. Which has the same implications as defined above, although only applying to a single process: Can be used for troubleshooting an issue in a single process without putting the entire system at risk by setting it to permissive. They allow an administrator to create policies for new applications without interfering with the rest of the system Booleans Minor modifications to SELinux policies can be made without modifying and recompiling the policy source by setting boolean values for optional features. Such features include allowing users to share their home directories under Samba or allowing Apache to serve files from users home directories which would otherwise be denied by the SELinux policy. 2.4 Utilities Show the current mode: $ getenforce Change the current mode to enforcing (non permanent): $ setenforce 1 Change the current mode to permissive (non permanent): $ setenforce 0 Configuration file: $ cat /etc/selinux/config Figure 5: Default configuration file Show security context of objects (files, folders, etc.): $ ls -Z 8

9 Figure 6: Security context of objects in / Show security context of subjects (running processes): $ ps auxz Figure 7: Security context of all processes running in the system Display the detailed status of a system running SELinux: $ /usr/sbin/sestatus -v Figure 8: SELinux Status Command to run a new shell in a new context, or role. Policy must allow the transition to the new role: $ /usr/bin/newrole Command to set the security context of one or more files by marking the extended attributes with the appropriate file or security context: $ /sbin/restorecon Command to check or correct the security context database on the file system: $ /sbin/fixfiles Command to list SELinux users: $ semanage user -l 9

10 Figure 9: SELinux Users Command to check the security context of logged user: $ id -Z 2.5 List of common problems Wrong Subject Context The program is running with the wrong subject context This happens when a program s executable file has the wrong context This happens when a third party software application installed and it is given an inappropriate SELinux file context This was fixed with a chcon command and the semanage commands. $ chcon --type=traceroute_exec_t /usr/bin/nmpa $ ls -Z /usr/bin/nmap $ -rwxr-xr-x. root root system_u:object_r:traceroute_exec_t:s0 /usr/vin/nmap $ semanage fcontext -a -t traceroute_exec_t /usr/bin/nmap Wrong Object Context The file begin accessed by the program has the wrong object context This can happen for any number of reasons The installation of third party software may result in files with wrong context because of inheritance from an upper level directory Often, configuration files end up with the wrong context as a result of how the system manager changes the configuration file. To repair the file, use the command: $ restorecon /path/to/file-name Right Subject and Object Context but No Access The program and the file have the correct contexts, but the policy should allow some operation between the two context, which is currently not allowed. In this case, it will be necessary to modify the SELinux policy First, consider looking threw the list of SELinux booleans for one that is related to the service which is not working using either getsebool or semanage. 10

11 3 How to install SELinux in a Debian System NOTE: These steps were checked and performed on an Virtual Machine running an instance of Ubuntu Get the default policy and the basic set of SELinux utilities by running: $ sudo apt-get install selinux-basics selinux-policy-default auditd 2. Download the _load_selinux_policy script (this is a slightly modified version of the script included in the Ubuntu selinux package), place it in /usr/share/initramfs-tools/scripts/initbottom/ then run: $ sudo update-initramfs -u 3. To configure GRUB and PAM and to create /.autorelabel run: $ sudo selinux-activate 4. Reboot, it will take a while to label the filesystems on boot and then it will automatically reboot a second time when that is complete. 5. To check that everything has been setup correctly and to catch common SELinux problems run: $ sudo check-selinux-installation You should now have a working SELinux system, which is in permissive mode. This means that the Policy is not enforced, but denials are logged. You can see all would-be denials since the last reboot with a small explanation for each with audit2why -al. If no critical audit errors appear in your syslog and you feel comfortable with SELinux, enable enforcing mode temporarily by running setenforce 1 or permanently by setting SELINUX=permissive on the config file located in /etc/selinux/config and then rebooting one last time. 11

12 4 Example Use Cases 4.1 MCS Usage Figure 10: Example categories To effectively use MCS, we need to be able to assign different sets of categories to different Linux users, even though they are all the same SELinux user (user_u). This is solved by introducing the concept of an SELinux login. This is used during the login process to assign MCS categories to Linux users when their shell is launched. Command to assign Linux users to SELinux user identities: $ semanage login -a Now when you list the SELinux users, you can see the Linux users assigned to a specific SELinux user identity: SELinux maintains a mapping between internal sensitivity and category levels and their humanreadable representations in the setrans.conf file. The system administrator edits this file to manage and maintain the required categories. Command to list the current categories: $ chcat -L 12

13 To modify the categories or to start creating our own, we need to modify the /etc/selinux/<selinuxtype>/setr file. For this example, we ll add the Marketing, Finance, Payroll and Personnel categories: Command to check the newly-added categories: $ chcat -L For these changes to take effect, we need to restart the MCS translation service as follows: Now that the required categories have been added to the system, we can start assigning them to SELinux subjects and objects. To further develop the example, let s assume that James is in the Marketing department, Daniel is in the Finance and Payroll departments, and Olga is in the Personnel department. Each of these users has already been assigned an SELinux login. Let us assign some categories to these users: List of users and respective categories after assigning: Let us now imagine we have the need to create a user for the CEO of the company Karl: 13

14 $ chcat We now need to assign categories to the various files on the system so that only the appropriate users can access them. For this example, we create a file in Daniel s home directory: Notice that at this stage the file has the default context for a file created in the user s home directory (user_home_t) and has no categories assigned to it. We can add the required category using the chcat command. Now when you check the security context of the file, you can see the category has been applied. In most cases, there is a need to assign more than one category to a file. For example, some files may need to be accessible to users from both the Finance and Payroll departments. Each of the categories that have been assigned to the file are displayed in the security context. It is possible to add or remove categories as required. Only users whose categories are a superset of the files categories are able to access it, assuming that Linux DAC and TE permissions would already allow the access. If a user who is assigned to a different category tries to access the file, they receive an error message: 14

15 5 Conclusion SELinux is a very mature product. NSA had been working on it for several years before releasing it to the Open Source community in December Even now it has been worked on by many individuals and companies. People in charge of application and data security will appreciate SELinux s robustness in dealing with zero-day exploits and poorly designed applications. Red Hat and Tresys both seem to be pretty interested in making SELinux easy to use and manage. Apart from RHEL and Fedora Core, users of Gentoo, Debian, and Ubuntu can also reap the benefits of SELinux. In addition to people interested in securing their desktop or their enterprise server, SELinux is also a good subject for students studying security in computer systems. It is a very vast topic and the main idea of this document was to give an overview of SELinux s architecture, methodologies and access control features. What the group found interesting was the level of modularity in the whole system and how easy it was to extend it or configure it for almost every need. References [1] Access Control [2] Mandatory Access Control (MAC) [3] Role Based Access Control (RBAC) [4] SELinux Wikipedia article [5] Secure Linux: Part 1. SELinux history of its development, architecture and operating principles [6] SELinux: Playing with fire [7] SELinux Wiki [8] SELinux - Gentoo Wiki [9] SELinux For Dummies (Video) [10] 2012 Red Hat Summit: SELinux For Mere Mortals (Video) [11] SELinux/Setup - Debian Wiki [12] Red Hat Enterprise Linux 6 Security-Enhanced Linux User Guide [13] Multi-Category Security (MCS) 15