A lot was discussed in the previous nine articles. This is the last article in this series. In this article i will in short repeat the steps to maximize the security that SELinux provides. Details about any of these steps can be found in the previous articles.
1. SELinux User.
Map Linux Users by default to a confined SELinux User. Think least privilege. Use for example guest_u: sudo semanage login -m -s guest_u -r s0-s0 __default__
If you wish to override the default SELinux User for a new Linux User then you can do so with the useradd and -Z option.
Do not map Linux users to the unconfined_u SELinux user. An exception to this rule can be the root user. Root users should not be allowed to login except via TTY in emergencies.
2. PAM SEPermit.
Add entries for all your confined SELinux Users to /etc/security/sepermit.conf to block logins when SELinux is in permissive mode.
You can decide to create a unique SELinux User for yourself that is exempted from SEPermit.
3. Permissive mode Vs. Permissive Domains.
Always prefer the use of Permissive Domains over Permissive Mode.
4. Do not modify your default SELinux Users. If you need a custom SELinux User and or SELinux user Domain then create a new one. You can base them of off existing ones.
5. Use Role based Access control to confine root and user privileges.
6. Do not modify existing Roles/ User Domains.
If you need a custom role then base it of off an existing role and map the new role to a new SELinux user. You can however map existing roles to new SELinux users.
7. Use sudo. Not SU and newrole.
8. Remove the unconfined domain(s).
Be sure to sudo semodule -r unconfined to disable system services that have no policy defined. use sudo semodule -r unconfineduser to completely disable unconfined user environments (not recommended) If you do decide to remove unconfineduser, then make sure to configure your SELinux User mappings to reflect this. Use sysadm instead of unconfined
I prefer unconfined User Domain over sysadm User Domain for a secondary all purpose privileged user domain because:
a. unconfined_login boolean can be set to disable unconfined user logins.
b. ssh_sysadm_login, and xdm_sysadm_login booleans do not work.
c. sysadm is a drunken unconfined.
d. root logins are disabled.
e. i only use unconfined user domain as a secundary privileged user domain that can only be accessed via sudo
e.1. except for the root Linux User which can only login via TTY in emergencies.
9. Remove as much policy as possible by either disabling or enabling booleans.
set unconfined_login to off
set xserver_object_manager to on
set *_exec_content to off
consider the secure_mode_booleans
What capabilities do I really need in my container? - I have written previous blogs discussing using linux capabilities in containers. - Secure Your Containers with this One Weird Trick - Container...
4 dagen geleden