| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| redhat:base-redhat:selinux-redhat [2017/09/18 09:57] – [Multi-Category Security (MCS)] 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. |
| |
| <WRAP center box 100%> | |
| | <WRAP center important 100%> |
| ==== Some of the Problems ==== | ==== Some of the Problems ==== |
| 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. |
| <WRAP center round important 100%> | <WRAP center round important 100%> |
| ''**Note:** When switching from Disabled to either Permissive or Enforcing mode, it is highly recommended that the system be rebooted and the filesystem relabeled.'' | ''**Note:** When switching from Disabled to either Permissive or Enforcing mode, it is highly recommended that the system be rebooted and the filesystem relabeled.'' |
| | </WRAP> |
| | |
| | ---- |
| | |
| | <WRAP center box 100%> |
| | ===== RPM dependencies to manage SELinux ===== |
| | Throughout this text, we already saw programs such as ''**semanage** from the rpm **policecoreutils-python** package **to manage our SELinux environment**''. If you missed installing it, we will begin this recipe by doing so (skip step 1 if you have already done this before): |
| | |
| | - Log in as root and install the following basic toolkit to work with SELinux: <code># yum install policycoreutils-python</code> |
| | - Now, we need some additional tools that will also be needed later in the SELinux Debugging:<code># yum install setools setools-console setroubleshoot*</code> |
| | - Next, install and configure the SELinux manual pages as they are not available by default on CentOS 7, but are important for getting detailed information about specific policies, security contexts, and SELinux Booleans later. First, we need to install another package: <code># yum install policycoreutils-devel</code> |
| | - Afterwards, let's generate all the man pages for all SELinux security context policies currently available on the system, and then update the manual pages database afterwards: <code># sepolicy manpage -a -p /usr/share/man/man8; mandb</code> |
| | |
| | |
| </WRAP> | </WRAP> |
| |
| 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. |
| |
| |
| |
| https://wiki.centos.org/HowTos/SELinux | https://wiki.centos.org/HowTos/SELinux |
| | |
| | |
| | |
| |
| |
| ---- | ---- |
| | |
| |
| ===== SELinux Troubleshooting ===== | ===== SELinux Troubleshooting ===== |
| <code># cat /var/log/audit/audit.log | grep avc</code> | <code># cat /var/log/audit/audit.log | grep avc</code> |
| |
| <sxh bash; gutter: false> | <sxh plain; gutter: false> |
| type=AVC msg=audit(1505717571.241:949): avc: denied { name_connect } for pid=1217 comm="java" dest=3306 scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket | type=AVC msg=audit(1505717571.241:949): avc: denied { name_connect } for pid=1217 comm="java" dest=3306 scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket |
| type=AVC msg=audit(1505717571.241:950): avc: denied { name_connect } for pid=1217 comm="java" dest=3306 scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket | type=AVC msg=audit(1505717571.241:950): avc: denied { name_connect } for pid=1217 comm="java" dest=3306 scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket |
| ==== Verwenden von Setools / Setroubleshoot ==== | ==== Verwenden von Setools / Setroubleshoot ==== |
| |
| * Installation von den Troubleshoot Packages: <code># yum install setroubleshoot setools</code> | * Installation von den Troubleshoot Packages //(Falls nicht schon vorhanden)//: <code># yum install setroubleshoot setools -y</code> |
| * Um nun die Fehler aus unserem Audit.log automatisiert auszuwerten folgenden Befehl ausführen: <WRAP center box 100%> | * Um nun die Fehler aus unserem Audit.log automatisiert auszuwerten folgenden Befehl ausführen: <WRAP center box 100%> |
| <code># sealert -a /var/log/audit/audit.log</code> | <code># sealert -a /var/log/audit/audit.log</code> |
| Jeder hier generierte Report, beschreibt zuerst den Fehler, und erklärt danach möglichst genau, wie das Problem behoben werden kann. Ausgabe des Befehls: | Jeder hier generierte Report, beschreibt zuerst den Fehler, und erklärt danach möglichst genau, wie das Problem behoben werden kann. Ausgabe des Befehls: |
| |
| <sxh bash; gutter: false> | <sxh plain; gutter: false> |
| [root@admin-server ~]# sealert -a /var/log/audit/audit.log | [root@admin-server ~]# sealert -a /var/log/audit/audit.log |
| 100% done | 100% done |
| |
| </sxh> | </sxh> |
| | </WRAP> |
| | |
| | * Wie oben ersichtlich, wird zu unserem Problem eine **Lösung durch Eingabe von folgenden zwei Befehlen** empfohlen: <WRAP center box 100%> |
| | <code> |
| | # ausearch -c 'java' --raw | audit2allow -M guacamole-java |
| | # semodule -i guacamole-java.pp |
| | </code> |
| | |
| | * ''**Der erste Befehl, erstellt im aktuellen Verzeichnis eine neue SELinux Regel** im ***.te Format (Text)** und **kompiliert** sie anschliessend in ein ***.pp Format.** //(Der in der Ausgabe verwendete Namen "my-java" kann beliebig festgelet werden! z.B. wie bei mir: guacamole-java)//'' |
| | * ''<wrap em>Mit dem zweiten Befehl, wird die Regel dann permanent aktiviert!</wrap>'' |
| | |
| </WRAP> | </WRAP> |
| |
| |
| | * http://www.serverlab.ca/tutorials/linux/administration-linux/troubleshooting-selinux-centos-red-hat/ |
| | * https://serverfault.com/questions/321301/how-do-i-view-the-contents-of-a-selinux-policy-package |
| | * https://www.centos.org/docs/5/html/Deployment_Guide-en-US/sec-sel-building-policy-module.html |
| | * https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Troubleshooting-Top_Three_Causes_of_Problems.html |
| |
| http://www.serverlab.ca/tutorials/linux/administration-linux/troubleshooting-selinux-centos-red-hat/ | |
| |
| |