Differences

This shows you the differences between two versions of the page.

--- redhat:base-redhat:selinux-redhat [2018/05/08 10:50] – [Introduction] michael
+++ redhat:base-redhat:selinux-redhat [2018/05/08 11:14] – [Role-Based Access Control (RBAC)] michael
@@ Line 102: / Line 102: @@
 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'''
@@ Line 148: / Line 148: @@
 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.
@@ Line 155: / Line 155: @@
 Although the default configuration of the targeted policy is to use unconfined logins, the administrator can quite easily switch to the **Role-Based Access Control** model. This model also switches to 'strict' mode for user domains, to allow targeting each program individually. To enable this, use **semanage-login** to add a login mapping for your user.
-FIXME
+<code>
+# semanage login -a -s "staff_u" -r "s0-s0:c0.c1023" <username>
+</code>
+The semanage-login command maps a Linux username to an SELinux user named "staff_u", with an MLS/MCS range of "s0-s0:c0.c1023". After this, logging in will result in ''**id -Z**'' returning  ''staff_u:staff_r:staff_t:s0-s0:c0.c1023'' opposed to unconfined_u:unconfined_r:unconfined_t:s0. Though staff_r is not a role meant for administration, it is a role that allows the user to change to other roles. When an admin would like to do system administration tasks they should switch to the sysadm_r role using the -r flag in **sudo**,
+<code>
+# sudo -r sysadm_r -i
+</code>
+This can be automated by adding a configuration file under /etc/sudoers.d/, to map the user to a default admin role.
+<sxh plain; gutter: false;>
+%wheel  ALL=(ALL)       TYPE=sysadm_t   ROLE=sysadm_r   ALL
+</sxh>
+It is still possible to login as an unconfined user or switch to the unconfined role via **newrole**, although the benefits of confined user domains are then lost. It is also possible to remove the ability to do this by creating a new SELinux user associated with only a select set of roles,
+<code>
+# semanage user -a -R "staff_r sysadm_r system_r -r "s0-s0:c0.c1023" my_staff_u
+</code>
+Then substituting staff_u for my_staff_u in the semanage-login command. Now attempting to switch to the unconfined_r role will result in an **AVC** and **SELINUX_ERR** message. If the admin wishes to remove the ability to login as an unconfined user completely, they should remap the __default__ login to a more suitable SELinux user, again using semanage-login.
+<code>
+# semanage login -m -s "user_u" -r "s0" __default__
+</code>
+If a user wishes to login as a role other than their default it is up to the login program to provide this functionality. SSH allows logging in with an alternative SELinux role by specifying it as part of the login identifier (e.g., as a staff user logging in as unconfined_r).
+<code>
+# ssh <username>/unconfined_r@hostname.net
+</code>
+The strict model that comes with Role-Based Access Control isn't perfect from a perspective of least privilege; running a quick search using policy analysis tools we can see that several confined programs can still read a users private SSH keys.
+<WRAP center box 100%>
+<code>
+# sesearch -ACS -t ssh_home_t -c file -p read
+</code>
+<sxh plain; gutter: false;>
+Found 132 semantic av rules:
+   allow snapperd_t file_type : file { ioctl read getattr lock open } ;
+   allow oddjob_mkhomedir_t user_home_type : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
+   allow mplayer_t non_security_file_type : file { ioctl read getattr lock open } ;
+   allow sendmail_t user_home_type : file { ioctl read getattr lock open } ;
+   allow systemd_tmpfiles_t non_auth_file_type : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename open } ;
+   allow login_pgm ssh_home_t : file { ioctl read getattr lock open } ;
+   allow ssh_keygen_t ssh_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
+   allow colord_t user_home_type : file { read getattr } ;
+   ... snip ...
+</sxh>
+</WRAP>
+''mplayer_t'' likely doesn't need to read SSH private keys, but it is granted access to that transiently by being allowed to read types of content associated with ''non_security_file_type'' that is allowing mplayer to read any content that isn't security related so the user can play multimedia from anywhere on the filesystem. This could be further constrained in the base SELinux policy, but as previously mentioned is not a major focus for the Upstream Vendor.
+Beyond the strict model, Role-Based Access Control also provides a mechanism for limiting the scope of what a user can do when they use **sudo** to switch to root. It is often desirable to enforce least privilege on users with specific roles like DBAs or auditors and the targeted policy includes several user roles for purposes like those, with documentation in their respective manual pages as mentioned in Policy Documentation.
+<WRAP center box 100%>
+<code>
+# seinfo -r
+</code>
+<sxh plain; gutter: false;>
+Roles: 14
+   auditadm_r
+   dbadm_r
+   guest_r
+   staff_r
+   user_r
+   logadm_r
+   object_r
+   secadm_r
+   sysadm_r
+   system_r
+   webadm_r
+   xguest_r
+   nx_server_r
+   unconfined_r
+</sxh>
+</WRAP>
+To map a user to one of these admin roles, the same semanage-user command is used as before to create a new SELinux user associated with the desired roles, and then semanage-login to associate the Linux login with the SELinux user. If the user should also be able to start system daemons they administrate from their user domain (i.e., to start mysql as dbadm_r for debugging from a shell) the  system_r role should be included in their list of associated roles.
+<code>
+# semanage user -a -R "staff_r system_r auditadm_r" -r "s0-s0:c0.c1023" auditor_u
+# semanage login -a -s "auditor_u" -r "s0-s0:c0.c1023" <username>
+</code>
 ====  Multi-Category Security (MCS) ====