SELinux Lockdown Part Eight: Unconfined

The unconfined space is for processes that require almost unrestricted access. Almost because writable memory execution is not permitted. The following permissions are restricted for processes that operate in the unconfined space unless specified otherwise: Execmem Execstack Execheap Execmod.

Processes that in a default Fedora 11 installation operate in this Unconfined Domain are the Linux Kernel, RPM, init scripts, and unconfined users.
Unconfined processes usually run programs unconfined too unless other otherwise specified. It is expected that unconfined processes are unrestricted and that children inherit this unconfined environment. Exceptions to this rule as said should be specified by creating policy that transitions the Unconfined Domain to a restricted space when a unconfined process runs a program.

Security can be greatly improved by removing the unconfined space. This will cause all processes to be restricted by SELinux. In Fedora 11 the unconfined space was split into two parts. The first part is the unconfined space for programs, and the second part is the unconfined space for users. This second part was renamed to the unconfineduser domain.

The result of this split is that now either or both environments can be removed. If the unconfined domain which is the domain for unconfined programs is removed then the init scripts will be restricted. This means that system services that do not have SELinux policy defined will run in the restricted init script environment and will not run unrestricted. This is a great way to ensure that no unrestricted system services are implemented on the system. The kernel and RPM processes stay unconfined because these processes need many permissions in order to operate successfully.

The unconfineduser domain can be removed to ensure that all users operate in a restricted environment. If it is decided to remove the unconfineduser domain than you must reconfigure your SELinux mappings to reflect this change.

There should be no reason to not remove the unconfined domain if the operator feels comfortable with SELinux. The operator can implement SELinux policy for any system process that does not have policy defined already.

The unconfineduser domain is usually handy to keep, as the operator can mannually configure which Linux users are mapped to this User Domain. SELinux can be configured to not allow unconfined logins via OpenSSH or Grapical User Interface. This means that users that have access to the unconfineduser domain can only login using this environment on the TTY or access the unconfined user space via the sudo command or SU with newrole command.

Using the unconfined user domain as a secondary domain only improves security if unconfined logins are not enabled.

Example: Remove the unconfined domain, disallow unconfined user logins, map unconfined_r role to existing staff_u SELinux User, Remove the sysadm_r role for the staff_u SELinux User. Add Linux user John and map the Linux user to the staff_u SELinux user. Add an entry for John to /etc/sudoers.

sudo setsebool -P unconfined_login off
sudo semanage user -m -L s0 -r s0-s0:c0.c1023 -R "staff_r system_r unconfined_r" -P user staff_u
sudo semodule -r unconfined
sudo useradd -Z staff_u john
sudo visudo (john ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r ALL)

John logs into the system as the restricted Linux user staff_u. When John wants to acquire root privileges he simply runs the sudo command. John can open a root shell in the unconfined space by running the sudo command with the -s option.

This configuration should not change your ways of doing things too much since root logins are not encouraged and since the staff_t restricted user domain has all permissions that a unprivileged user requires. It is also possible to create a custom User Domain that is tailor made to your personal requirements and map its role to a custom SELinux Users together with the system_r and unconfined_r role. That way you can keep the staff_u SELinux User in its original state and can you modify your User Domain and SELinux user to your requirements.

Conclusion:

Consider removing the Unconfined Domain and or the Unconfineduser Domain to improve security.

Refer: man semanage, man semodule, man visudo, man setsebool, man sudo