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:
parent
9cbd84f07d
commit
b5b0034191
1 changed files with 9 additions and 89 deletions
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue