1
0
mirror of https://github.com/privacyguides/privacyguides.org.git synced 2025-07-24 12:21:09 +00:00

Less reliance on external resources

This commit is contained in:
2022-04-23 17:19:08 -05:00
committed by Daniel Gray
parent 313696132a
commit 33dc6b1211
6 changed files with 18 additions and 17 deletions

View File

@@ -24,9 +24,9 @@ If you are using non-classic [Snap](https://en.wikipedia.org/wiki/Snap_(package_
There are some additional kernel hardening options such as configuring [sysctl](https://en.wikipedia.org/wiki/Sysctl#Linux) keys and [kernel command-line parameters](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) which are described in the following pages. We dont recommend you change these options unless you learn about what they do.
- [2.2 Sysctl](https://madaidans-insecurities.github.io/guides/linux-hardening.html#sysctl)
- [2.3 Boot parameters](https://madaidans-insecurities.github.io/guides/linux-hardening.html#boot-parameters)
- [2.5 Kernel attack surface reduction](https://madaidans-insecurities.github.io/guides/linux-hardening.html#kernel-attack-surface-reduction)
- [Recommended sysctl settings](https://madaidans-insecurities.github.io/guides/linux-hardening.html#sysctl)
- [Recommended boot parameters](https://madaidans-insecurities.github.io/guides/linux-hardening.html#boot-parameters)
- [Additional recommendations to reduce the kernel's attack surface](https://madaidans-insecurities.github.io/guides/linux-hardening.html#kernel-attack-surface-reduction)
Note that setting `kernel.unprivileged_userns_clone=0` will stop Flatpak, Snap (that depend on browser-sandbox), Electron based AppImages, Podman, Docker, and LXC containers from working. Do **not** set this flag if you are using container products.
@@ -54,7 +54,7 @@ If you use [Toolbox](https://docs.fedoraproject.org/en-US/fedora-silverblue/tool
## Linux Pluggable Authentication Modules (PAM)
There is also further hardening to [PAM](https://en.wikipedia.org/wiki/Linux_PAM) to secure authentication to your system. [14. PAM](https://madaidans-insecurities.github.io/guides/linux-hardening.html#pam) has some tips on this.
There is also further hardening to [PAM](https://en.wikipedia.org/wiki/Linux_PAM) to secure authentication to your system. [This guide](https://madaidans-insecurities.github.io/guides/linux-hardening.html#pam) has some tips on this.
On Red Hat distributions you can use [`authselect`](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel) to configure this e.g.:
@@ -72,7 +72,7 @@ Another alternative option if youre using the [linux-hardened](#linux-hardene
## Secure Boot
[Secure Boot](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_Boot) can be used to secure the boot process by preventing the loading of [unsigned](https://en.wikipedia.org/wiki/Public-key_cryptography) [UEFI](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface) drivers or [boot loaders](https://en.wikipedia.org/wiki/Bootloader). Some guidance for this is provided in [21. Physical security](https://madaidans-insecurities.github.io/guides/linux-hardening.html#physical-security) and [21.4 Verified boot](https://madaidans-insecurities.github.io/guides/linux-hardening.html#verified-boot).
[Secure Boot](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_Boot) can be used to secure the boot process by preventing the loading of [unsigned](https://en.wikipedia.org/wiki/Public-key_cryptography) [UEFI](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface) drivers or [boot loaders](https://en.wikipedia.org/wiki/Bootloader). Some guidance for this is provided in [this physical security guide](https://madaidans-insecurities.github.io/guides/linux-hardening.html#physical-security) and [this verified boot guide](https://madaidans-insecurities.github.io/guides/linux-hardening.html#verified-boot).
For further resources on Secure Boot we suggest taking a look at the following for instructional advice:

View File

@@ -24,9 +24,9 @@ Hard-coded access to some kernel interfaces like [`/sys`](https://en.wikipedia.o
### Firejail
[Firejail](https://firejail.wordpress.com/) is another method of sandboxing. As it is a large [setuid](https://en.wikipedia.org/wiki/Setuid) binary, it has a large [attack surface](https://en.wikipedia.org/wiki/Attack_surface) which may assist in [privilege escalation](https://en.wikipedia.org/wiki/Privilege_escalation).
[Firejail](https://firejail.wordpress.com/) is another method of sandboxing. As it is a large [setuid](https://en.wikipedia.org/wiki/Setuid) binary, it has a large attack surface which may assist in [privilege escalation](https://en.wikipedia.org/wiki/Privilege_escalation).
The main risk is that Firejail may make the system safer from processes confined by it, but make it also less safe from processes running outside of Firejail. We [dont recommend](https://madaidans-insecurities.github.io/linux.html#firejail) the use of Firejail.
[This post from a Whonix security researcher](https://madaidans-insecurities.github.io/linux.html#firejail) provides additional details on how Firejail can worsen the security of your device.
### Mandatory Access Control
@@ -55,7 +55,7 @@ For advanced users, you can make your own AppArmor profiles, SELinux policies, B
If youre running a server you may have heard of Linux Containers, Docker, or Podman which refer to a kind of [OS-level virtualization](https://en.wikipedia.org/wiki/OS-level_virtualization). Containers are more common in server and development environments where individual apps are built to operate independently.
[Docker](https://en.wikipedia.org/wiki/Docker_(software)) is one of the most common container solutions. It does not run a proper sandbox, and this means that there is a large kernel [attack surface](https://en.wikipedia.org/wiki/Attack_surface). The [daemon](https://en.wikipedia.org/wiki/Daemon_(computing)) controls everything and [typically](https://docs.docker.com/engine/security/rootless/#known-limitations) runs as root. If it crashes for some reason, all the containers will crash too. The [gVisor](https://en.wikipedia.org/wiki/GVisor) runtime which implements an application level kernel can help limit the number of [syscalls](https://en.wikipedia.org/wiki/System_call) an application can make and can help isolate it from the hosts [kernel](https://en.wikipedia.org/wiki/Kernel_(operating_system)).
[Docker](https://en.wikipedia.org/wiki/Docker_(software)) is one of the most common container solutions. It does not run a proper sandbox, and this means that there is a large kernel attack surface. The [daemon](https://en.wikipedia.org/wiki/Daemon_(computing)) controls everything and [typically](https://docs.docker.com/engine/security/rootless/#known-limitations) runs as root. If it crashes for some reason, all the containers will crash too. The [gVisor](https://en.wikipedia.org/wiki/GVisor) runtime which implements an application level kernel can help limit the number of [syscalls](https://en.wikipedia.org/wiki/System_call) an application can make and can help isolate it from the hosts [kernel](https://en.wikipedia.org/wiki/Kernel_(operating_system)).
Red Hat develops [Podman](https://docs.podman.io/en/latest/) and secures it with SELinux to [isolate](https://www.redhat.com/sysadmin/apparmor-selinux-isolation) containers from each other. One of the notable differences between Docker and Podman is that Docker requires [root](https://en.wikipedia.org/wiki/Superuser) while Podman can run with [rootless containers](https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics) that are also [daemonless](https://developers.redhat.com/blog/2018/08/29/intro-to-podman), meaning if one crashes they dont all come down.