Remove GrSecurity/PAX and trim down SELinux

Now that GrSecurity/PaX are no longer available for free download, it is
almost impossible to get it without paying significant amounts of money.
Remove them from the recommendation, but mention that it remains a
viable option for anyone who has a subscription.

Additionally, trim down the SELinux section to remove the detailed
instructions on audit2allow and staff_u. Such details are probably
best suited for a dedicated document.

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
This commit is contained in:
Konstantin Ryabitsev 2017-11-15 15:47:42 -05:00
parent 9cbd84f07d
commit b5b0034191
No known key found for this signature in database
GPG Key ID: 34BAB80AF9F247B8
1 changed files with 9 additions and 89 deletions

View File

@ -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