skip to main |
skip to sidebar
The SELinux Permissive Mode is a state where SELinux permits violation of SELinux policy system wide. In this system wide permissive state policy violations are merely logged. Permissive Mode can be used to troubleshoot and test SELinux related issues. The complication with a system wide permissive state is that is is wise to operate it in a safe environment and out of production. In some rare scenarios one could consider minimizing the risks that come with Permissive Mode by using the SEPermit Pluggable Authentication Module, but often this measure is not suffice because that only disables Linux user logins. System services remain vulnerable to policy violations.
Recently SELinux Permissive Domains were introduced to mitigate these issues. With Permissive Domains one can run a single SELinux Security Domain in a permissive state. By using Permissive Domains you can keep your system in production and for example disable public access to the Permissive Domain using IPTables, TCP Wrappers, PAM or using other methods.
The semanage command can be used to add and delete SELinux Permissive Domains. You do need to know in which Security Domain a process runs in order to make this Security Domain a Permissive Domain. The ps command used with the -Z option can help you find this information.
Example of how to make the Security Domain called httpd_t for Apache a Permissive Domain:
sudo semanage permissive -a httpd_t
Example of how to make the Security Domain called httpd_t for Apache be enforced again by SELinux:
sudo semanage permissive -d httpd_t
Example of how to use the semanage command to list SELinux Permissive Domains:
sudo semanage permissive -lConclusion:
Prefer SELinux Permissive Domains over Permissive Mode.
Add, list and delete Permissive domains with the semanage command.Refer: man semanage, man tcpd, man pam_sepermit, man iptables
In a previous article i discussed the advantage of mapping Linux users to confined SELinux users. There may be times when you are required to troubleshoot issues on the system or solve issues that require you to operate in SELinux Permissive Mode.
The SELinux Permissive Mode is a state in which SELinux restrictions are not enforced. SELinux does however audit SELinux policy violations that would have normally be prevented. Look at Permissive Mode as a Intrusion Detection System where Enforcing Mode could be considered a Intrusion Prevention System.
In most cases one will want to move the system out of production whilst operating in Permissive Mode. In some cases this may not be so easy.
There are ways to minimize the risks involved with Permissive Mode. A feature that was recently introduced called SELinux Permissive Domains is a preferred method to accomplish this. Permissive Domains will be discussed in a later chapter.
The Pluggable Authentication Module called SEPermit can also help minimizing exposure of Permissive Mode.
PAM SEPermit can disable Linux user logins when the system operates in Permissive Mode. Consider operating a system where your local Linux users are restricted by SELinux. Permissive Mode effectively lifts those restrictions. Linux users may take advantage of this by accessing resources they would otherwise be restricted to use.
In Fedora 11 PAM SEPermit is enabled by default in the various appropriate files in /etc/pam.d/ like for example /etc/pam.d/sshd. One can simply configure SEPermit to disable Linux user logins in Permissive mode by adding Linux users and or SELinux users to the SEPermit configuration file located in /etc/security/sepermit.conf.
Appending %user_u to your sepermit.conf file in /etc/security for example, disable login for SELinux user user_u when the system is in Permissive Mode.
Be aware that SELinux Permissive Mode however also lifts SELinux restrictions for processes other then Linux users like for example system services.
In most cases you are still encouraged to move your system out of the Demilitarized Zone when troubleshooting issues in Permissive Mode. PAM SEPermit can however be helpful in some cases.
Try it out!
Conclusion:
Prefer SELinux Permissive Domains over SELinux Permissive Mode.
If Permissive Mode in a live environment is required on a system with SELinux restricted Linux users then you are encourage to disable Linux user logins with the SEPermit Pluggable Authentication Module.
Be aware that this only affects Linux Users and that system services will not be protected by SELinux in Permissive Mode.
refer: man pam_sepermit, man setenforce, man getenforce
This article is the first in a series about tightening SELinux configuration for Fedora 11.
In Fedora 11, Linux users by default are mapped to the unconfined_u SELinux user. The unconfined_u SELinux user is mapped to the unconfined_r, system_r roles and to all available Multi Category Security compartments.
Both unconfined_r and system_r are roles that map to SELinux security domains. SELinux security domains are defined security environments for processes on the Linux system.
The unconfined security domain, unconfined_t, is a environment reserved for processes that are to a large extend exempted from SELinux restrictions. The system_r role maps to security domains for system processes.
The unconfined_u SELinux user has access to the system_r role to be able to run system processes in their security domains. SELinux user unconfined_u operates in the unconfined_t security domain via the unconfined_r role that it is mapped to.
The semanage command can be used to add, modify and delete Linux user to SELinux user mappings, as well as other settings related to SELinux management. Alternatively the system-config-selinux graphical user interface to semanage can be used to modify these settings.
To use the semanage command to list to which SELinux user, Linux users get mapped by default type: sudo semanage login -l | grep default
__default__ unconfined_u SystemLow-SystemHigh
In the example above Linux users are mapped to the unconfined_u SELinux user by default.
To modify this configuration to map Linux users by default to a confined SELinux user called user_u simply type: sudo semanage login -m -s user_u "__default__"
This will map new Linux users to the restricted user_u SELinux user by default.
You can override this mapping when you run the useradd command to add Linux users with the -Z option. This option specifies to which SELinux user the Linux user should be mapped. For example type: sudo useradd -Z guest_u joe
The usermod command with -Z option can also be used to modify a Linux user to SELinux user mapping.
This will add a Linux user called joe and will map joe to the guest_u SELinux user instead of mapping joe to the defined default SELinux user.
There are some SELinux user profiles predefined. These profiles can be listed with the semanage command. type: sudo semanage user -l
Next i will discuss some of the properties of these predefined SELinux users.
The guest_u SELinux user:
This profile is used for users that need to be tightly controlled. The guest_u SELinux user can only log in using OpenSSH. Guest users have no access to network resources, setuid, setgid programs.
The xguest_u SELinux user:
This profile is identical to that of guest_u. The exception is that Xguest users can only log in to Xwindows and cannot log in using OpenSSH. Another exception of Xguest users is that this partical user can access HTTP port using a SELinux restricted instance of Mozilla Firefox.
The user_u SELinux user:
The user_u SELinux user resembles a ordinary unprivileged SELinux confined user. This user can log in using Xwindows and OpenSSH, has access to network resources, but cannot use setuid and setgid programs.
The staff_u SELinux user:
This SELinux user is identical to user_u except that staff_u can access setuid and getgid programs. The staff_u SELinux user can also stat all process on the system amongst other minor extra privileges compared to user_u.
The sysadm_u SELinux user:
This user is designed for SELinux restricted root login, which is not recommended. This SELinux user is used in a Multi Level Security Environment where there is no unconfined_u.
The unconfined_u SELinux user:
The unconfined_u SELinux user is the environment where all Linux users are mapped to be default in Fedora Targeted policy. This user is to a large extend exempted from SELinux confinement. The exception is Memory Execution Protections.
Real Linux users, not root, should not be mapped to the unconfined_u SELinux user group if you want to improve security on your system. In many scenarios having unconfined users on a system creates a gaping hole in security.
Root logins should be prohibited always. Root should only be able to log in using the terminal in case of an emergency. In Fedora, the Linux user root is mapped to unconfined_u. This means that root logins are almost not protected by SELinux.
The improve the security of root logins one could map the root Linux user to the sysadm_u SELinux user. Although this does not provide much security over unconfined_u, and root will be able to bypass SELinux security.
Bottom line is that root logins should not be permitted except on the terminals in case of emergency.
The system_u SELinux user:
This SELinux user profile is reserved for the system. Linux users should not be mapped to the System_u SELinux user.
I explained how one can define a default SELinux user for new Linux users by default, and i explained how one can override this with the useradd command and -Z option.
The available predefined SELinux users were explained. What is left is to show how SELinux user mappings to Linux users can be altered.
To list all Linux user to SELinux user mappings:
sudo semanage login -l
To manually map a Linux user to a SELinux user:
sudo semanage login -a (...)
To modify a Linux user to SELinux user mapping:
sudo semanage -m (...)
To delete a Linux user to SELinux uper mapping:
sudo semanage -d (...)
Conclusion:
Configure SELinux to map Linux users to confined SELinux users by default to improve security.
Disallow root logins using OpenSSH and Xwindows altogether. Allow root to only login using the terminal in case of emergency. Either leave the root Linux user mapping to the unconfined_u SELinux user or map root to sysadm_u. (for example if you decide to de-install the unconfineduser SELinux module)
Map your Linux users to the appropriate confined SELinux user by using the profile that best fits.
Use the useradd command with -Z option to add Linux users, overriding the default Linux user to SELinux user mapping by the SELinux user that you pass as its argument.
Refer: man semanage, man useradd, man usermod
