misc. edits authored by Opt Out's avatar Opt Out
...@@ -6,9 +6,9 @@ ...@@ -6,9 +6,9 @@
- Hardened Memory Allocator system-wide LD_PRELOAD - Hardened Memory Allocator system-wide LD_PRELOAD
- This is ported over from the [GrapheneOS project](https://github.com/GrapheneOS/hardened_malloc) and complements the MUSL codebase well. See [here](https://github.com/GrapheneOS/hardened_malloc#security-properties) for further elaboration on the security properties of hardened_malloc. - This is ported over from the [GrapheneOS project](https://github.com/GrapheneOS/hardened_malloc) and complements the MUSL codebase well. See [here](https://github.com/GrapheneOS/hardened_malloc#security-properties) for further elaboration on the security properties of hardened_malloc.
- Hardened Kernel with patchsets and trimming - Hardened Kernel with patchsets and trimming
- The Linux kernel is a monolithic mess that is vulnerable to classes of exploitation. Patchsets and gutted kernel modules stand to limit the attack surface, and thus kill off classes of exploitation. Further details can be found [here](https://git.arrr.cloud/whichdoc/plague-kernel). - The Linux kernel is a monolithic mess that is vulnerable to classes of exploitation. Patchsets and gutted kernel modules stand to limit the attack surface, and thus kill off classes of exploitation. Further details can be found [here](https://0xacab.org/optout/plague-kernel).
- Kernel Boot Parameters - Kernel Boot Parameters
- The GRUB_CMDLINE_LINUX_DEFAULT line in `/etc/default/grub` contains parameters used to mitigate a variety of software and hardware related vulnerabilities. These parameters stand to complement the already hardened [plague-kernel](https://git.arrr.cloud/whichdoc/plague-kernel) configuration. While there is no one-size fits all for every mitigation across all hardware, we are attempting to perform a balancing act between hardening and system performance. See [linux-hardened](https://raw.githubusercontent.com/anthraxx/linux-hardened/5.10/Documentation/admin-guide/kernel-parameters.txt) kernel documentation and [hardware vulnerability](https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/) related parameters. - The GRUB_CMDLINE_LINUX_DEFAULT line in `/etc/default/grub` contains parameters used to mitigate a variety of software and hardware related vulnerabilities. These parameters stand to complement the already hardened [plague-kernel](https://0xacab.org/optout/plague-kernel) configuration. While there is no one-size fits all for every mitigation across all hardware, we are attempting to perform a balancing act between hardening and system performance. See [linux-hardened](https://raw.githubusercontent.com/anthraxx/linux-hardened/5.10/Documentation/admin-guide/kernel-parameters.txt) kernel documentation and [hardware vulnerability](https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/) related parameters.
- `intel_iommu` & `amd_iommu` - Pass parameters to the Intel/AMD IOMMU driver in the system. - `intel_iommu` & `amd_iommu` - Pass parameters to the Intel/AMD IOMMU driver in the system.
- `iommu=force` - Enforces the use of IOMMU. - `iommu=force` - Enforces the use of IOMMU.
- `iommu.strict=1` was previously used, however due to performance issues this has since been removed. - `iommu.strict=1` was previously used, however due to performance issues this has since been removed.
...@@ -29,7 +29,7 @@ ...@@ -29,7 +29,7 @@
- The XTS mode of operation has been selected over CBC as it is considered less malleable than CBC, however it should be noted that neither cipher is meant for integrity protection, but XTS is excellent at confidentiality as recommended by [NIST SP800-38E](https://csrc.nist.gov/publications/detail/sp/800-38e/final). [BTRFS](https://www.kernel.org/doc/html/latest/filesystems/btrfs.html) filesystem alleviates the concern by providing checksums for all data and metadata on the disk. - The XTS mode of operation has been selected over CBC as it is considered less malleable than CBC, however it should be noted that neither cipher is meant for integrity protection, but XTS is excellent at confidentiality as recommended by [NIST SP800-38E](https://csrc.nist.gov/publications/detail/sp/800-38e/final). [BTRFS](https://www.kernel.org/doc/html/latest/filesystems/btrfs.html) filesystem alleviates the concern by providing checksums for all data and metadata on the disk.
- Argon2id - Argon2id
- Argon2id was selected as the key derivation function cipher as it currently holds the best combined [side-channel](https://en.wikipedia.org/wiki/Side-channel_attack) resistance, parallelism resistance, and [time memory trade-off attack](https://en.wikipedia.org/wiki/Time/Memory/Data_Tradeoff_attack) resistance. - Argon2id was selected as the key derivation function cipher as it currently holds the best combined [side-channel](https://en.wikipedia.org/wiki/Side-channel_attack) resistance, parallelism resistance, and [time memory trade-off attack](https://en.wikipedia.org/wiki/Time/Memory/Data_Tradeoff_attack) resistance.
- The chosen cryptographic cipher and key derivation (KDF) can be altered by editing the following lines prior to install in the [env.cfg](https://git.arrr.cloud/whichdoc/plagueos/-/blob/master/installerScripts/env.cfg) file: - The chosen cryptographic cipher and key derivation (KDF) can be altered by editing the following lines prior to install in the [env.cfg](https://0xacab.org/optout/plagueos/-/blob/master/installerScripts/env.cfg) file:
- CIPHER="aes-xts-plain64" -> "serpent" - CIPHER="aes-xts-plain64" -> "serpent"
- KEY_SIZE="512" -> "1024" - KEY_SIZE="512" -> "1024"
...@@ -48,12 +48,12 @@ ...@@ -48,12 +48,12 @@
- WIP: Nuke LUKS keys by using a special passphrase (See reference [here](https://gitlab.com/kalilinux/packages/cryptsetup-nuke-keys)) - WIP: Nuke LUKS keys by using a special passphrase (See reference [here](https://gitlab.com/kalilinux/packages/cryptsetup-nuke-keys))
- The Cryptsetup package with the LUKS nuke feature is planned due to its anti-forensic nature. In short, this allows the user to configure a secondary passphrase that could be leveraged when under duress to nuke the LUKS headers, rendering the host's data permanently encrypted. (Note: The headers can be restored with a backup) - The Cryptsetup package with the LUKS nuke feature is planned due to its anti-forensic nature. In short, this allows the user to configure a secondary passphrase that could be leveraged when under duress to nuke the LUKS headers, rendering the host's data permanently encrypted. (Note: The headers can be restored with a backup)
- Blacklisted kernel modules, file systems, & network protocols - Blacklisted kernel modules, file systems, & network protocols
- Sysctl parameters and modprobe blacklist are passed to configure various security features & disable unnecessary or dangerous features to reduce attack surface. Our sysctl parameters are listed [here](https://git.arrr.cloud/WhichDoc/plagueOS/src/branch/master/configs/etc/sysctl.d) and the blacklist is listed [here](https://git.arrr.cloud/WhichDoc/plagueOS/src/branch/master/configs/etc/modprobe.d/blacklist.conf). Do note that many of the legacy modules/protocols highlighted in the modprobe blacklist are already mitigated at the kernel level and is largely redundant. - Sysctl parameters and modprobe blacklist are passed to configure various security features & disable unnecessary or dangerous features to reduce attack surface. Our sysctl parameters are listed [here](https://0xacab.org/optout/plagueOS/src/branch/master/configs/etc/sysctl.d) and the blacklist is listed [here](https://0xacab.org/optout/plagueOS/src/branch/master/configs/etc/modprobe.d/blacklist.conf). Do note that many of the legacy modules/protocols highlighted in the modprobe blacklist are already mitigated at the kernel level and is largely redundant.
- IPTables Packet Filtering - IPTables Packet Filtering
- IPTables is a local packet filter that is configured on plagueOS to deny all inbound and forwarding traffic. - IPTables is a local packet filter that is configured on plagueOS to deny all inbound and forwarding traffic.
- Introduced a rewrite of Whonix's hide-hardware-info script that has a working implementation. - Introduced a rewrite of Whonix's hide-hardware-info script that has a working implementation.
- Increased Entropy with use of `haveged` and `jitterentropy` - Increased Entropy with use of `haveged` and `jitterentropy`
- All strong cryptographic implementations rely on entropy or randomness. To increase entropy on GNU/Linux systems, the packages `haveged` and `jitterentropy` can be used along with the boot parameter `random.trust_cpu=off` in the `/etc/default/grub` file. See [Madaidan's Linux hardening guide](https://madaidans-insecurities.github.io/guides/linux-hardening.html#entropy) and [Into the Crypt: The Art of Anti-Forensics](https://git.arrr.cloud/arcanedev/into-the-crypt#cryptography) for more details on system entropy. - All strong cryptographic implementations rely on entropy or randomness. To increase entropy on GNU/Linux systems, the packages `haveged` and `jitterentropy` can be used along with the boot parameter `random.trust_cpu=off` in the `/etc/default/grub` file. See [Madaidan's Linux hardening guide](https://madaidans-insecurities.github.io/guides/linux-hardening.html#entropy) and [Into the Crypt: The Art of Anti-Forensics](https://0xacab.org/optout/into-the-crypt#cryptography) for more details on system entropy.
- Increased password hashing rounds - Increased password hashing rounds
- Full Wayland Environment options - Full Wayland Environment options
- Wayland environments were prioritized due to their implementation of windows isolation, which Xorg lacks. Xorg windows with a nested X11 server and a sandboxing tool such as `bwrap` could accomplish this, however Wayland provides the better model by default. We currently leverage `gnome-core` as the desktop environment to provide a minimalist, easy-to-use interface. - Wayland environments were prioritized due to their implementation of windows isolation, which Xorg lacks. Xorg windows with a nested X11 server and a sandboxing tool such as `bwrap` could accomplish this, however Wayland provides the better model by default. We currently leverage `gnome-core` as the desktop environment to provide a minimalist, easy-to-use interface.
...@@ -64,14 +64,14 @@ ...@@ -64,14 +64,14 @@
- UMASK 0077 to system-wide default - UMASK 0077 to system-wide default
- `umask` sets the default file permissions for newly created files. This makes new files unreadable by anyone other than the owner. - `umask` sets the default file permissions for newly created files. This makes new files unreadable by anyone other than the owner.
- Secure fstab configuration - Secure fstab configuration
- See the set fstab [configuration](https://git.arrr.cloud/WhichDoc/plagueOS/src/branch/master/configs/etc/fstab) detailing restrictions set to mount points. `nodev`, `nosuid`, and `noexec` are a few of the set flags that were applied to specific mount points. - See the set fstab [configuration](https://0xacab.org/optout/plagueOS/src/branch/master/configs/etc/fstab) detailing restrictions set to mount points. `nodev`, `nosuid`, and `noexec` are a few of the set flags that were applied to specific mount points.
- Locked `root` account, `admin` account for elevated privileges - Locked `root` account, `admin` account for elevated privileges
- Use of doas over sudo - Use of doas over sudo
- The package [doas](https://wiki.archlinux.org/title/Doas) is a simple alternative to `sudo` which forces a password entry for every command issued, unlike sudo which has a specified time in a shell where it will retain full administrative function. - The package [doas](https://wiki.archlinux.org/title/Doas) is a simple alternative to `sudo` which forces a password entry for every command issued, unlike sudo which has a specified time in a shell where it will retain full administrative function.
- Generic Machine ID - Generic Machine ID
- The machine ID is altered to a generic identifier to reduce host fingerprinting. - The machine ID is altered to a generic identifier to reduce host fingerprinting.
- Randomized MAC address for Network Interface Controllers (NIC) - Randomized MAC address for Network Interface Controllers (NIC)
- The implementation for randomizing the MAC address includes the use of `bwrap` in the [plague-macchanger](https://git.arrr.cloud/WhichDoc/plagueOS/src/branch/master/bin/plague-macchanger) service. This alters the MAC upon every boot rather than every new connection. We mimic vendor identifiers in the first bits and randomize the last half. Having a completely random MAC address stands to make your device an anomaly rather than blending. - The implementation for randomizing the MAC address includes the use of `bwrap` in the [plague-macchanger](https://0xacab.org/optout/plagueOS/src/branch/master/bin/plague-macchanger) service. This alters the MAC upon every boot rather than every new connection. We mimic vendor identifiers in the first bits and randomize the last half. Having a completely random MAC address stands to make your device an anomaly rather than blending.
- [USBGuard](https://usbguard.github.io/) Implementation - [USBGuard](https://usbguard.github.io/) Implementation
- This prevents arbitrary mounting of USBs that could be malicious. This is a reduction on physical attack surface. On plagueOS, USBGuard must whitelist USB connections from the privileged `admin` account. The USBGuard implementation is not a perfect mitigation, however it is sufficient to prevent automounting for most threat models. The issue is when the adversary has physical access and could attempt to spoof the identifier of whitelisted devices, allow them to connect said unwelcome USB. The best solution, which is likely to come to fruition soon is deny USBs from the kernel level and allow them access via USBCTL. This is a planned feature. - This prevents arbitrary mounting of USBs that could be malicious. This is a reduction on physical attack surface. On plagueOS, USBGuard must whitelist USB connections from the privileged `admin` account. The USBGuard implementation is not a perfect mitigation, however it is sufficient to prevent automounting for most threat models. The issue is when the adversary has physical access and could attempt to spoof the identifier of whitelisted devices, allow them to connect said unwelcome USB. The best solution, which is likely to come to fruition soon is deny USBs from the kernel level and allow them access via USBCTL. This is a planned feature.
- Encrypted DNS with [DNSCrypt](https://github.com/DNSCrypt/dnscrypt-proxy) by default. - Encrypted DNS with [DNSCrypt](https://github.com/DNSCrypt/dnscrypt-proxy) by default.
... ...
......