diff --git a/base_configs/home/user/PlagueOS_Wiki/Debug.md b/base_configs/home/user/PlagueOS_Wiki/Debug.md new file mode 100644 index 0000000000000000000000000000000000000000..36d83229cd4e15f3eb1184bcacc9ef5c96264578 --- /dev/null +++ b/base_configs/home/user/PlagueOS_Wiki/Debug.md @@ -0,0 +1,51 @@ +# Overview +Like all projects, there are going to be inevitable hiccups along the way. Some of the errors can be self-corrected, and we want to ensure that issues that have been debugged are recorded appropriately so that no one has to reinvent the wheel. + +## Installer Issues +A variety of issues can crop up with the installer such as: +- Spotty connections can halt the download +- Staging can change over time - particularly with Whonix / Kicksecure +- Changed dependencies +- Base machine's clock is skewed +- A file reference could be missing or misplaced + +In short, a proper connection via Ethernet, installation over clearnet rather than TOR, and pre-determining an accurate clock time can save you a lot of headache. + +--- + +## Baseline PlagueOS issues + +### Libvirt / virt-manager +#### Virtual Machines (VM) not starting +1. Is this your first boot? + - If so, open `virt-manager`, select `Connection Details` -> `Virtual Networks` + - Select each virtual network individually, ensure `On Boot` is checked, and click the start / play button at the bottom to ensure the network is turned on. + +#### Virtual Machines (VM) not displaying +1. Is `virt-manager` not displaying your VMs? + - From a privileged user (i.e. admin or root), run the following commands: + - `sv restart virtlogd` + - `sv restart virtlockd` + - `sv restart libvirtd` + - Reopen `virt-manager` and the VMs should appear + +### Kernel level +Kernel security, particularly with PlagueOS, is generally untrodden ground. Not many seek out this esoteric level of security. Many are initimidated by the kernel layer, and documentation surrounding this topic is an utter mess. + +#### Adding built-in modules +The Linux kernel is primarily known for this statement - "It just works." +This is problematic for the security enthusiast who does not want to support legacy modules from the 90's. + +The modules are signed by an ephemeral signing key during compilation. If the kernel is missing a necessary driver for your operations, there are limited way to correct this. +1. You wait for our team to get around to pushing an update to the kernel, and you run the `plague-update` script from a privileged user +2. You take action into your own hands and self-compile. Before you call us maniacs for suggesting this, we have built a script for self-compiling. The Plague Kernel [self_compilation.sh](https://0xacab.org/optout/plague-kernel/self_compilation.sh) script does all of the legwork. + - A quick note regarding this, we would strongly advise running with the default Plague kernel configuration rather than the fingerprinting hardware option to start. You can optionally choose to open the kernel configuration menu, and then select the module(s) with you are missing. This search can be done by running `/` in the UI that appears. + + We do not advise trying to fingerprint your hardware while trying to make things work. This could vastly overcomplicate the problem, and could even result in an unbootable kernel. We wish that we could provide full assurances that we could guarantee a working, self-compiled kernel on a variety of different hardware and software, however this sadly is not a reality. + +#### Adding external modules +This is indeed a limitation. The Plague Kernel & self-compile script are designed to sign the present modules and then burn the ephemeral signing key. We also have no desire or plans to bake in third party modules during our upstream build process. + +If you need external driver(s) that are not supported in the upstream Linux kernel, the only solutions you have are as follows: +- Install and run with the LTS kernel and forfeit the mitigations of the minimalist / hardened kernel +- Self-compile and bake in 3rd party module diff --git a/base_configs/home/user/PlagueOS_Wiki/Development.md b/base_configs/home/user/PlagueOS_Wiki/Development.md index 49e6ddb633d847d456d811b393fb17e56f5dc071..622ddc46ed0527bed2007605de7a422974410eed 100644 --- a/base_configs/home/user/PlagueOS_Wiki/Development.md +++ b/base_configs/home/user/PlagueOS_Wiki/Development.md @@ -36,7 +36,7 @@ $ gpg --list-secret-keys --keyid-format=long ------------------------------------ sec 4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10] -uid Hubot +uid Hubot ssb 4096R/42B317FD4BA89E7A 2016-03-10 ``` Secondly, set signingkey via terminal: @@ -49,16 +49,16 @@ Add key to bash profile: if [ -r ~/.bash_profile ]; then echo 'export GPG_TTY=$(tty)' >> ~/.bash_profile; \ else echo 'export GPG_TTY=$(tty)' >> ~/.profile; fi ``` - + ### To sign commits - + `git commit -S -m "your commit message"` (Keep comments short & direct) `git push` ## Frequently Used Git commands ### Pull Repository down locally -`git clone git@0xacab.org:optout/plagueOS.git` +`git clone git@0xacab.org:WhichDoc/plagueOS.git` ### Update branch w/ remote dev `git remote add upstream https://0xacab.org/optout/plagueos` diff --git a/base_configs/home/user/PlagueOS_Wiki/Donations.md b/base_configs/home/user/PlagueOS_Wiki/Donations.md index 0b7d4962943d9eb983373b45d68c8e79eef8b9bc..45d81a05121d7098d0e7aff3ee22982c423aa5f1 100644 --- a/base_configs/home/user/PlagueOS_Wiki/Donations.md +++ b/base_configs/home/user/PlagueOS_Wiki/Donations.md @@ -1,5 +1,5 @@ -Donations to support projects under [WhichDoc](https://0xacab.org/optout) are welcome with Monero (XMR) in the spirit of cryptography and anti-forensics. +Donations to support current and related works are welcome with Monero (XMR) in the spirit of cryptography and anti-forensics. Monero (XMR): `47w2kanKMnzFkRGnSvbYjjPYac9TAsAm2GzmPBprdqM41zVXHSgkkSmVJMrY6o1qoYLdVJabcBupnJbABMxu4ejrMArAEue` -Also listed in [Into the Crypt: The Art of Anti-Forensics](https://0xacab.org/optout/into-the-crypt) \ No newline at end of file +Also listed in [Into the Crypt: The Art of Anti-Forensics](https://0xacab.org/optout/into-the-crypt#donations) diff --git a/base_configs/home/user/PlagueOS_Wiki/FAQ.md b/base_configs/home/user/PlagueOS_Wiki/FAQ.md index aaf1ff8c0a43533addda0473e9ea05e49fc87185..07eb934936d13d7571bad7932854558f25d133a4 100644 --- a/base_configs/home/user/PlagueOS_Wiki/FAQ.md +++ b/base_configs/home/user/PlagueOS_Wiki/FAQ.md @@ -1,10 +1,15 @@ - How does this differ from QubesOS? - - [QubesOS](https://www.qubes-os.org/) has some downsides such as computational power required to run every single process as a VM and it throttles the host. Outdated templates are a huge issue with qubes. Not to mention the difficulty of routing xen via tor on the main host. For these reasons, Whonix even started [Whonix-Host](https://www.whonix.org/wiki/Whonix-Host) which is the same idea of this project. Albeit, they've been slow with their implementation. + - [QubesOS](https://www.qubes-os.org/) has some downsides such as computational power required to run the majority of processes as a VM, and thus throttles the host. Keeping templates updated is not a trivial task with Qubes. Not to mention the difficulty of routing Xen via TOR on the main host. For these reasons, Whonix even started [Whonix-Host](https://www.whonix.org/wiki/Whonix-Host) which is the same idea of this project. Albeit, they've been slow with their implementation. - How would someone compromise PlagueOS? - - To fully compromise the host, one would have to find a way to exploit the running VM, perform a sandbox escape from libvirt, find a way to exploit some running process or create a reverse shell from the unprivileged user, then break credentials for the admin account, which requires the use of doas for privilege escalation. We have stringent apparmor profile on libvirt (kvm). We also have developed a bwrap sandbox for libvirt, however process execution of the VMs took a substantial performance hit. + - To fully compromise the host, one would have to find a way to exploit the running VM, perform a sandbox escape from libvirt, find a way to exploit some running process or create a reverse shell from the unprivileged user, then break credentials for the admin account, which requires the use of doas for privilege escalation. We have a stringent apparmor profile on libvirt (kvm). We also have developed a bwrap sandbox for libvirt, however process execution of the VMs took a substantial performance hit. This performance issue is likely due to our implementation of GrapheneOS's hardened_malloc. - Can regular GNU/Linux applications be installed? - - Applications are heavily restricted with this build and must be installed with `doas` privilege escalation with the `admin` account. The security of this OS follows a strict hypervisor usage model; installing applications breaks the [usage model](https://0xacab.org/optout/plagueOS/wiki/Home#proper-usage) and should be conducted at the user's own risk. + - Applications are heavily restricted with this build and must be installed with `doas` privilege escalation with the `admin` account. The security of this OS follows a strict hypervisor usage model; installing applications breaks the [usage model](https://0xacab.org/optout/plagueOS/wiki/Home#proper-usage) and should be conducted at the user's own risk. - Is there an offline installation? - An offline installer is a planned feature; however this will not be available in the immediate future. For best use, an installation via ethernet is advised. - Are there hardware limitations? - - There is not specific hardware that is required to run PlagueOS. As a whole, we recommend having at least 8GB of RAM for the guests (VMs), however this is not required. Old hardware can run the base install in an efficient manner. We should note that ARM architectures are not currently supported. \ No newline at end of file + - There is not specific hardware that is required to run PlagueOS. As a whole, we recommend having at least 8GB of RAM for the guests (VMs), however this is not required. Old hardware can run the base install in an efficient manner. We should note that ARM architectures are not currently supported. + - Certain vendors have unique requirements with UEFI. Void Linux stages the grub binary under the directory `/boot/efi/EFI/Void/grubx64.efi`. For non-compliant vendors that require GRUB to be staged in a standard directory without additional checks, run the following command: `cp /boot/efi/EFI/Void/grubx64.efi /boot/efi/EFI/boot/bootx64.efi` + - See [Void Documentation](https://docs.voidlinux.org/installation/guides/chroot.html#installing-on-removable-media-or-non-compliant-uefi-systems) +- Can PlagueOS be used as a VM guest? I would like to leverage the many hardening features PlagueOS configures by default. + - Absolutely - although the main limitations include being aware of applications being largely restricted with the mix of MUSL, runit, and xbps packaging. + - Note: If using PlagueOS as a guest while using libvirt qemu, remember to disable/modify the default libvirt qemu networking within the PlagueOS guest itself, as the redundancy interferes with networking and internet access. diff --git a/base_configs/home/user/PlagueOS_Wiki/Security-Considerations.md b/base_configs/home/user/PlagueOS_Wiki/Security-Considerations.md index d8c9bf6de55dc88bfd11eb398556f0c33eb595fe..0006a2c1a8b736228699ba958d1fab2dba8c78ba 100644 --- a/base_configs/home/user/PlagueOS_Wiki/Security-Considerations.md +++ b/base_configs/home/user/PlagueOS_Wiki/Security-Considerations.md @@ -21,7 +21,7 @@ - `tsx_async_abort=full` - Enable TAA mitigation on vulnerable CPUs if TSX is enabled. - `l1tf=flush` - Leaves SMT enabled and enables the default hypervisor mitigation, i.e. conditional L1D flushing. - `mds=full` - Enables Micro-architectural Data Sampling (MDS) mitigation on vulnerable CPUs - - `nosmt=force` - Disable symmetric multithreading (SMT). Do note that this parameter can lead to performance issues. + - `mitigations=auto,nosmt` - Disable symmetric multithreading (SMT). Do note that this parameter can lead to performance issues, but it will only disable SMT when the CPU is known to be vulnerable. Unimpacted CPU's will still run with the full amount of system cores. - FDE Custom LUKS Encryption (AES256XTS+Argon2id KDF) - Cipher primitives - AES256-XTS @@ -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. - 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. - - 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/installer_scripts/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" - KEY_SIZE="512" -> "1024" @@ -57,7 +57,7 @@ - Increased password hashing rounds - 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. - - Optional client only environment made available for those who chose to implement other environments. + - Window Manager options are still under consideration, however, few truly abide by the Wayland security model as observed with Sway WM (which we previously supported). - Hide process identifiers - By default, all users can view snoop on process identifiers, which could be leveraged by an attacker to spy on processes. We mount `/proc` with `hidepid=2,gid=proc` mount options. - Permission hardening diff --git a/base_configs/home/user/PlagueOS_Wiki/home.md b/base_configs/home/user/PlagueOS_Wiki/home.md index 4deda2518d9580fe2cd1e812ff9b2feec94bd0b9..57f5dfbc8618dbaecde26a8b5d3ef8b608d53231 100644 --- a/base_configs/home/user/PlagueOS_Wiki/home.md +++ b/base_configs/home/user/PlagueOS_Wiki/home.md @@ -1,5 +1,5 @@ # About PlagueOS -PlagueOS is not associated with the TOR project, Whonix, or Void Linux. +PlagueOS is not associated with the TOR project or Whonix. This is not developed by an organization; this is a passion project created and maintained by a few Linux enthusiasts. This OS is not resistant to all forms of exploitation; there are shortcomings inherent to the modern desktop environment that we are attempting to mitigate. The OS is designed to run KVM as a minimalist hypervisor with security-centric virtual machines (guests) from `virt-manager`. diff --git a/base_configs/plague/runit/plague-time-sync/run b/base_configs/plague/runit/plague-time-sync/run index 084a689dfa37423528901b5a6308bf87613da55e..eb63ca850fdd3abab112d587a151eff0db330729 100644 --- a/base_configs/plague/runit/plague-time-sync/run +++ b/base_configs/plague/runit/plague-time-sync/run @@ -1,4 +1,7 @@ #!/bin/bash +# Adding sleep timer to prevent failed query during boot +sleep 30 + exec 2>&1 bwrap --ro-bind / / --dev-bind /dev/ /dev/ --share-net --die-with-parent --new-session --cap-drop all --cap-add CAP_SYS_TIME /plague/bin/plague-time-sync sleep 21600 \ No newline at end of file