| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| redhat:base-redhat:selinux-redhat [2018/01/09 15:04] – [Verwenden von Setools / Setroubleshoot] michael | redhat:base-redhat:selinux-redhat [2018/05/08 11:01] – [SELinux Access Control] michael |
|---|
| ===== Introduction ===== | ===== Introduction ===== |
| |
| **Security-Enhanced Linux (SELinux)** is a mandatory access control (MAC) security mechanism implemented in the kernel. SELinux was first introduced in CentOS 4 and significantly enhanced in later CentOS releases. These enhancements mean that content varies as to how to approach SELinux over time to solve problems. | **Security-Enhanced Linux (SELinux)** ist ein obligatorischer Zugriffskontrollmechanismus - //mandatory access control// (MAC), der im Kernel implementiert ist. SELinux wurde zuerst in CentOS 4 / Red Hat 4 eingeführt und in späteren Versionen erheblich verbessert. |
| |
| |
| In order to better understand why SELinux is important and what it can do for you, it is easiest to look at some examples. Without SELinux enabled, only traditional discretionary access control (DAC) methods such as file permissions or access control lists (ACLs) are used to control the file access of users. Users and programs alike are allowed to grant insecure file permissions to others or, conversely, to gain access to parts of the system that should not otherwise be necessary for normal operation. For example: | In order to better understand why SELinux is important and what it can do for you, it is easiest to look at some examples. Without SELinux enabled, only traditional discretionary access control (DAC) methods such as file permissions or access control lists (ACLs) are used to control the file access of users. Users and programs alike are allowed to grant insecure file permissions to others or, conversely, to gain access to parts of the system that should not otherwise be necessary for normal operation. For example: |
| |
| * Administrators have no way to control users: A user could set world readable permissions on sensitive files such as ssh keys and the directory containing such keys, customarily: ~/.ssh/ | * ''Administrators have no way to control users: A user could set world readable permissions on sensitive files such as ssh keys and the directory containing such keys, customarily: ~/.ssh/'' |
| * Processes can change security properties: A user's mail files should be readable only by that user, but the mail client software has the ability to change them to be world readable | * ''Processes can change security properties: A user's mail files should be readable only by that user, but the mail client software has the ability to change them to be world readable'' |
| * Processes inherit user's rights: Firefox, if compromised by a **trojaned** version, could read a user's private ssh keys even though it has no reason to do so. | * ''Processes inherit user's rights: Firefox, if compromised by a **trojaned** version, could read a user's private ssh keys even though it has no reason to do so.'' |
| |
| Essentially under the traditional DAC model, there are two privilege levels, root and user, and no easy way to enforce a model of least-privilege. Many processes that are launched by root later drop their rights to run as a restricted user and some processes may be run in a chroot jail but all of these security methods are discretionary. | Essentially under the traditional DAC model, there are two privilege levels, root and user, and no easy way to enforce a model of least-privilege. Many processes that are launched by root later drop their rights to run as a restricted user and some processes may be run in a chroot jail but all of these security methods are discretionary. |
| The **targeted** SELinux policy on Redhat/CentOS ships with **4 forms of access control**: | The **targeted** SELinux policy on Redhat/CentOS ships with **4 forms of access control**: |
| |
| * <wrap em>Type Enforcement (TE):</wrap> Type Enforcement is the primary mechanism of access control used in the targeted policy | * ''<wrap em>Type Enforcement (TE):</wrap>'' Type Enforcement is the primary mechanism of access control used in the targeted policy |
| * <wrap em>Role-Based Access Control (RBAC):</wrap> Based around SELinux users (not necessarily the same as the Linux user), but not used in the default configuration of the targeted policy | * ''<wrap em>Role-Based Access Control (RBAC):</wrap>'' Based around SELinux users (not necessarily the same as the Linux user), but not used in the default configuration of the targeted policy |
| * <wrap em>Multi-Level Security (MLS):</wrap> Not commonly used and often hidden in the default targeted policy. | * ''<wrap em>Multi-Level Security (MLS):</wrap>'' Not commonly used and often hidden in the default targeted policy. |
| * <wrap em>Multi-Category Security(MCS):</wrap> An extension of Multi-Level Security, used in the targeted policy to implement compartmentalization of virtual machines and containers through sVirt. | * ''<wrap em>Multi-Category Security(MCS):</wrap>'' An extension of Multi-Level Security, used in the targeted policy to implement compartmentalization of virtual machines and containers through [[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/chap-security-enhanced_linux-svirt|sVirt]]. |
| |
| ''<wrap em>All processes and files have an SELinux security context!</wrap> Let's see these in action by looking at the SELinux security context of the Apache homepage: '/var/www/html/index.html''' | ''<wrap em>All processes and files have an SELinux security context!</wrap> Let's see these in action by looking at the SELinux security context of the Apache homepage: '/var/www/html/index.html''' |
| here we see the type is user_home_t, the default type for files in a user's home directory. | here we see the type is user_home_t, the default type for files in a user's home directory. |
| |
| Access is only allowed between similar types, so Apache running as httpd_t can read /var/www/html/index.html of type httpd_sys_content_t. Because Apache runs in the httpd_t domain and does not have the userid:username, it can not access **/home/username/myfile.txt** even though this file is world readable because **/home/username/myfile.txt** SELinux security context is not of type httpd_t. If Apache were to be exploited, assuming for the sake of this example that the **root** account right needed to effect a SELinux re-labeling into another context were not obtained, it would not be able to start any process not in the httpd_t domain (which prevents escalation of privileges) or access any file not in an httpd_t related domain. | Access is only allowed between similar types, so Apache running as ''httpd_t'' can read /var/www/html/index.html of type ''httpd_sys_content_t''. Because Apache runs in the httpd_t domain and does not have the userid:username, it can not access **/home/username/myfile.txt** even though this file is world readable because **/home/username/myfile.txt** SELinux security context is not of type httpd_t. If Apache were to be exploited, assuming for the sake of this example that the **root** account right needed to effect a SELinux re-labeling into another context were not obtained, it would not be able to start any process not in the httpd_t domain (which prevents escalation of privileges) or access any file not in an httpd_t related domain. |
| |
| |