| Both sides previous revision Previous revision | Next revisionBoth sides next revision |
| redhat:base-redhat:selinux-redhat [2018/05/08 10:50] – [Introduction] michael | redhat:base-redhat:selinux-redhat [2018/05/08 11:01] – [SELinux Access Control] michael |
|---|
| 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. |
| |
| |