diff --git a/linux-workstation-security.md b/linux-workstation-security.md index a449c4e..a496e87 100644 --- a/linux-workstation-security.md +++ b/linux-workstation-security.md @@ -173,7 +173,7 @@ what you should consider when picking a distribution to use. ### Checklist -- [ ] Has a robust MAC/RBAC implementation (SELinux/AppArmor/GrSecurity) _(ESSENTIAL)_ +- [ ] Has a robust MAC/RBAC implementation (SELinux/AppArmor) _(ESSENTIAL)_ - [ ] Publishes security bulletins _(ESSENTIAL)_ - [ ] Provides timely security patches _(ESSENTIAL)_ - [ ] Provides cryptographic verification of packages _(ESSENTIAL)_ @@ -182,7 +182,7 @@ what you should consider when picking a distribution to use. ### Considerations -#### SELinux, AppArmor, and GrSecurity/PaX +#### SELinux and AppArmor Mandatory Access Controls (MAC) or Role-Based Access Controls (RBAC) are an extension of the basic user/group security mechanism used in legacy POSIX @@ -197,11 +197,13 @@ post-installation. Distributions that do not provide any MAC/RBAC mechanisms should be strongly avoided, as traditional POSIX user- and group-based security should be considered insufficient in this day and age. If you would like to start out -with a MAC/RBAC workstation, AppArmor and GrSecurity/PaX are generally -considered easier to learn than SELinux. Furthermore, on a workstation, where -there are few or no externally listening daemons, and where user-run -applications pose the highest risk, GrSecurity/PaX will offer more security -benefits than just SELinux. +with a MAC/RBAC workstation, AppArmor is generally considered easier to learn +than SELinux. + +GrSecurity/PaX is no longer offered as a free download and, as a result, +almost every publicly available distribution has stopped providing it. If this +option remains available to you through your employer, you may choose to +continue using GrSecurity/PaX on your workstation. #### Distro security bulletins @@ -755,13 +757,6 @@ If you are using a distribution that comes bundled with SELinux (such as Fedora), here are some recommendation of how to make the best use of it to maximize your workstation security. -#### Checklist - -- [ ] Make sure SELinux is enforcing on your workstation _(ESSENTIAL)_ -- [ ] Never blindly run `audit2allow -M`, always check _(ESSENTIAL)_ -- [ ] Never `setenforce 0` _(NICE)_ -- [ ] Switch your account to SELinux user `staff_u` _(NICE)_ - #### Considerations SELinux is a Mandatory Access Controls (MAC) extension to core POSIX @@ -777,81 +772,6 @@ to gain root-level access via a vulnerable daemon service. Our recommendation is to leave it on and enforcing. -##### Never `setenforce 0` - -It's tempting to use `setenforce 0` to flip SELinux into permissive mode -on a temporary basis, but you should avoid doing that. This essentially turns -off SELinux for the entire system, while what you really want is to -troubleshoot a particular application or daemon. - -Instead of `setenforce 0` you should be using `semanage permissive -a -[somedomain_t]` to put only that domain into permissive mode. First, find out -which domain is causing troubles by running `ausearch`: - - ausearch -ts recent -m avc - -and then look for `scontext=` (source SELinux context) line, like so: - - scontext=staff_u:staff_r:gpg_pinentry_t:s0-s0:c0.c1023 - ^^^^^^^^^^^^^^ - -This tells you that the domain being denied is `gpg_pinentry_t`, so if you -want to troubleshoot the application, you should add it to permissive domains: - - semanage permissive -a gpg_pinentry_t - -This will allow you to use the application and collect the rest of the AVCs, -which you can then use in conjunction with `audit2allow` to write a local -policy. Once that is done and you see no new AVC denials, you can remove that -domain from permissive by running: - - semanage permissive -d gpg_pinentry_t - -##### Use your workstation as SELinux role staff_r - -SELinux comes with a native implementation of roles that prohibit or grant -certain privileges based on the role associated with the user account. As an -administrator, you should be using the `staff_r` role, which will restrict -access to many configuration and other security-sensitive files, unless you -first perform `sudo`. - -By default, accounts are created as `unconfined_r` and most applications you -execute will run unconfined, without any (or with only very few) SELinux -constraints. To switch your account to the `staff_r` role, run the following -command: - - usermod -Z staff_u [username] - -You should log out and log back in to enable the new role, at which point if -you run `id -Z`, you'll see: - - staff_u:staff_r:staff_t:s0-s0:c0.c1023 - -When performing `sudo`, you should remember to add an extra flag to tell -SELinux to transition to the "sysadmin" role. The command you want is: - - sudo -i -r sysadm_r - -At which point `id -Z` will show: - - staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 - -**WARNING**: you should be comfortable using `ausearch` and `audit2allow` -before you make this switch, as it's possible some of your applications will -no longer work when you're running as role `staff_r`. At the time of writing, -the following popular applications are known to not work under `staff_r` -without policy tweaks: - -- Chrome/Chromium -- Skype -- VirtualBox - -To switch back to `unconfined_r`, run the following command: - - usermod -Z unconfined_u [username] - -and then log out and back in to get back into the comfort zone. - ## Further reading The world of IT security is a rabbit hole with no bottom. If you would like to