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 (...)
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
Container Labeling - An issue was recently raised on libpod, the github repo for Podman. *"container_t isn't allowed to access container_var_lib_t"* Container policy is defin...
4 weken geleden