Reorganize (#72)

* Reorganize

Signed-off-by: Tommy <contact@tommytran.io>

content/posts/qubes/Firewalling with MirageOS on Qubes OS.md

@@ -0,0 +1,97 @@
+---
+title: "Firewalling with MirageOS on Qubes OS"
+date: 2022-08-26
+tags: ['Operating Systems', 'MirageOS', 'Qubes OS', 'Security']
+author: Tommy
+---
+
+![MirageOS](/images/mirageos.png)
+
+[MirageOS](https://mirage.io/) is a library operating system with which you can create a unikernel for the sole purpose of acting as Qubes OS's firewall. In this post, I will walk you through how to set this up.
+
+## Advantages
+- Small attack surface. The unikernel only contains a minimal set of libraries to function, so it has a much smaller attack surface than a general purpose operating system like a Linux distribution or openBSD.
+- Low resource consumption. You only need about 64MB of RAM for each instance of the Mirage Firewall.
+- Fast startup time.
+
+## Disadvantages
+- No official package for Qubes OS and while [Qubes Mirage Firewall](https://github.com/mirage/qubes-mirage-firewall) is still maintained, it rarely gets an official release. This means that you need to follow the development process on GitHub and make a new build yourself whenever there is a new commit.
+- Does not work well with the Windows PV network driver. With that being said, the Windows PV networking driver is pretty buggy on its own, and I don't recommend that you use it anyways.
+
+### Prebuilt Image
+
+You can obtain a prebuilt image of MirageOS [here](https://github.com/tommytran732/QubesOS-Scripts/tree/main/mirageos). I do follow the development of Qubes Mirage Firewall (since I use it on my personal computer) and will be uploading builds frequently.
+
+### Building Mirage-Firewall Yourself
+
+First, you need to make sure that you have Docker installed on your system. Then, run the following commands:
+
+```bash
+git clone https://github.com/palainp/qubes-mirage-firewall/
+cd qubes-mirage-firewall
+git checkout mirage4
+sudo ./build-with-docker.sh
+```
+Once the build process finishes, the unikernel should be at `~/qubes-mirage-firewall/_build/mirage-firewall/vmlinuz`.
+
+## Deploy
+
+First, you need to copy the unikernel to `/var/lib/qubes/vm-kernels/mirage-firewall` in `dom0` and create a dummy `initramfs`:
+
+```bash
+mkdir -p /var/lib/qubes/vm-kernels/mirage-firewall/
+cd /var/lib/qubes/vm-kernels/mirage-firewall/
+qvm-run -p your_appvm_name 'cat /path/to/the/vmlinuz/file' > vmlinuz
+gzip -n9 < /dev/null > initramfs
+```
+### TemplateVM
+
+Create a TemplateVM:
+
+```bash
+qvm-create \
+  --property kernel=mirage-firewall \
+  --property kernelopts='' \
+  --property memory=128 \
+  --property maxmem=128 \
+  --property vcpus=1 \
+  --property virt_mode=pvh \
+  --label=black \
+  --class TemplateVM \
+  your_template_name
+``` 
+
+Don't worry if the TemplateVM doesn't launch - we don't need it to.
+
+### Disposable Template
+
+Next, create a disposable template based on the TemplateVM you have just created.
+
+```bash
+qvm-create \
+  --property template=your_template_name \
+  --property provides_network=True \
+  --property template_for_dispvms=True \
+  --label=orange \
+  --class AppVM \
+  your_disposable_template_name
+
+qvm-features your_disposable_template_name qubes-firewall 1
+qvm-features your_disposable_template_name no-default-kernelopts 1
+``` 
+
+Your disposable templates should now launch and shutdown properly.
+
+### Disposable FirewallVMs
+
+You can now create disposable FirewallVMs based on your disposable template. I recommend replacing `sys-firewall` with a disposable Mirage firewall. If you use ProxyVMs like `sys-whonix`, I recommend that you add a disposable Mirage Firewall after the ProxyVM as well, and use it as the net qube for your AppVMs. 
+
+```bash
+qvm-create \
+  --property template=your_disposable_template_name \
+  --property provides_network=True \
+  --property netvm=your_net_qube_name \
+  --label=orange \
+  --class DispVM \
+  your_firwall_name
+```

content/posts/qubes/Using Lokinet on Qubes OS.md

@@ -0,0 +1,74 @@
+---
+title: "Using Lokinet on Qubes OS"
+date: 2022-07-27
+tags: ['Applications', 'Qubes OS', 'Anonymity', 'Privacy']
+author: Tommy
+---
+
+![Lokinet](/images/lokinet.png)
+
+[Lokinet](https://lokinet.org) is an Internet overlay network utilizing onion routing to provide anonymity for its users, similar to Tor network. This post will provide a quick (and non exhaustive) list of its [pros](#advantages) and [cons](#disadvantages) from an end user perspective and go over how to set it up on Qubes OS.
+
+## Advantages
+
+- Provides anonymity by removing trust in a service provider (as opposed to a traditional VPN)
+- Better versatility than Tor by supporting any IP based protocols (Tor only supports TCP)
+- Generally faster speed than the Tor Network
+
+## Disadvantages
+
+- Only works well on Debian-based distributions. The client for Windows has DNS Leaks, and support for macOS, Android, and other Linux distributions is experimental. It should be noted that this is a problem with the official client, not the protocol itself.
+- Does not have a killswitch which could lead to accidental leaks (as opposed to common commercial VPN clients which lock the connections to just the provider's servers).
+- The official client requires a user to manually define an exit node, or to set certain IP ranges to be routed through certain exit nodes. While this makes it possible to setup some form of Steam Isolation, it is not as good as Tor's `isolateDestinationAddr` and `isolateDesitnationPort`. which automatically use a random exit node for every destination/port you visit.
+- DNS does not work when used as a ProxyVM on Qubes OS
+
+## Creating the TemplateVM
+
+As mentioned [above](#disadvantages), the Lokinet client only works well with Debian-based distributions. This means that our template will have to be one of the Debian-based ones, and I would highly recommend that you convert the official Debian template by the Qubes OS team into a KickSecure template to use as a base. KickSecure reduces the attack surface of Debian with a substantial set of hardening configurations, and a nice feature to go with an anonymity network like Lokinet is [Boot Clock Randomization](https://www.kicksecure.com/wiki/Boot_Clock_Randomization) which helps defend against [time-based denonymization attacks](https://www.whonix.org/wiki/Time_Attacks). You will only need the `kicksecure-cli` meta package (`kicksecure-gui` is unnecessary), and experimental services like `proc-hidepid`, `hide-hardware-info` and `permission-hardening` work just fine with the Lokinet client. [Hardened Malloc](https://www.kicksecure.com/wiki/Hardened_Malloc) and [LKRG](https://www.kicksecure.com/wiki/Linux_Kernel_Runtime_Guard_LKRG) do not cause any problem with Lokinet, either.
+
+Since DNS with Lokinet does not work if it is installed inside of a ProxyVM, we will need to have Lokinet running inside the same AppVM as the applications you intend to run. This is less than ideal, as a compromised AppVM could reveal your IP address. Beyond that, accidental leaks can happen, too.
+
+A potential solution to this problem is to set up an unbound server or firewall script redirecting all DNS traffic to the ProxyVM to its Lokinet DNS server at `127.3.2.1:53`; however, I have been unable to get it working. Another solution is to simply override the DNS server inside the AppVM to a custom DNS server, but this will make you stand out out and break `.loki` DNS resolution. Websites like [DNS leak test](https://dnsleaktest.com) can observe which DNS server you are actually using and potentially fingerprint you. For the same reason that you should not use custom DNS servers when connected to the Tor network, you really should not use a custom DNS server when connected to Lokinet.
+
+Start by importing the Oxen's PGP key:
+
+`sudo curl --proxy http://127.0.0.1:8082 -so /etc/apt/trusted.gpg.d/oxen.gpg https://deb.oxen.io/pub.gpg`
+
+Then, add Oxen's Debian repository:
+
+`echo "deb https://deb.oxen.io $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/oxen.list`
+
+Next, update the repositories:
+
+`sudo apt update`
+
+If updates for your packages are found, **DO NOT** attempt to upgrade them directly. Instead, use the Qubes Updater to update the TemplateVM.
+
+When you are done, install `lokinet-gui` and `resolvconf`:
+
+`sudo apt install lokinet-gui resolvconf`
+
+Note that you **must** install `resolveconf` to get DNS working.
+
+Next, edit `/var/lib/lokinet/lokinet.ini` and add the exit server you want to use:
+
+`exit-node=exit.loki`
+
+Note that I am using `exit.loki` here, as it is the one mentioned in the [Lokinet documentation](https://docs.oxen.io/products-built-on-oxen/lokinet/exit-nodes).
+There are some other exit servers listed on [probably.loki](http://probably.loki/wiki/index.php?title=Exit_Nodes) as well, and for your convenience, I will just copy-paste them here:
+
+- `exit.loki` (USA, run by Jeff)
+- `exit2.loki` (USA, run by Jeff, same ip as exit.loki)
+- `xite.loki` (Iceland, run by Loutchi)
+- `peter.loki` (USA, run by peter)
+- `secret.loki` (Netherlands, run by Secret)
+
+Finally, enable the `lokinet` service:
+
+`systemctl enable lokinet`
+
+## Creating the AppVM
+
+Just create the AppVM as usual, and you would be good to go. There are a few things to keep in mind though:
+- You should probably set networking to use `sys-firewall`. I have tested using my ProtonVPN ProxyVM for networking, and DNS was not working. Besides, it makes little sense to attempt such setup anyways, unless you are worried about accidental leaks or a compromised AppVM.
+- You should give the AppVM the `network-manager` service so that Lokinet can set up networking properly and get DNS working.

content/posts/qubes/Using Mullvad VPN on Qubes OS.md

@@ -0,0 +1,71 @@
+---
+title: "Using Mullvad VPN on Qubes OS"
+date: 2022-09-03
+tags: ['Applications', 'Qubes OS', 'Privacy']
+author: Tommy
+---
+
+![Mullvad VPN](/images/mullvad-vpn-1.png)
+
+Mullvad is a fairly popular and generally trustworthy VPN provider. In this post, I will walk you through how to use the official Mullvad client in a ProxyVM on Qubes OS. This method is a lot more convenient than the [official guide](https://mullvad.net/en/help/qubes-os-4-and-mullvad-vpn/) from Mullvad (which recommends that you manually load in OpenVPN or Wireguard profiles) and will let you seamlessly switch between different location and network setups just as you would on a normal Linux installation.
+
+## Preparing your TemplateVM
+
+I recommend that you make a new TemplateVM based on latest Fedora template and remove all unnecessary packages that you might not use. This way, you can minimize the attack surface while not having to deal with missing dependencies like on a minimal template. With that being said, if you do manage to get the minimal template to fully work with Mullvad, feel free to [open a discussion on GitHub](https://github.com/orgs/PrivSec-dev/discussions) or [contact me directly](https://tommytran.io/contact) and I will update the post accordingly.
+
+This is what I run on my template to trim it down:
+```bash
+sudo dnf remove firefox thunderbird totem gnome-remote-desktop gnome-calendar gnome-disk-utility gnome-calculator gnome-connections gnome-weather gnome-contacts gnome-clocks gnome-maps gnome-screenshot gnome-logs gnome-characters gnome-font-viewer gnome-color-manager simple-scan keepassxc cheese baobab yelp evince* httpd mozilla* cups rygel -y
+sudo dnf autoremove -y
+```
+
+Next, you need to create the bind directories for Mullvad's configurations:
+
+```bash
+sudo mkdir -p /etc/qubes-bind-dirs.d
+sudo tee /etc/qubes-bind-dirs.d/50_user.conf << EOF > /dev/null
+binds+=( '/etc/mullvad-vpn' )
+EOF
+```
+
+## Installing the Mullvad App
+
+Inside of the TemplateVM you have just created, do the following:
+
+```bash
+sudo dnf install https://mullvad.net/media/app/MullvadVPN-2022.5_x86_64.rpm
+sudo systemctl enable mullvad-daemon
+```
+
+Replace `https://mullvad.net/media/app/MullvadVPN-2022.5_x86_64.rpm` with whatever the latest URL for the Mullvad App is. I will try to update this post to give you the accurate command, but you should just take them from [their website](https://mullvad.net/en/download/linux/).
+
+![Mullvad VPN URL](/images/mullvad-vpn-2.png)
+
+Shutdown the TemplateVM:
+
+```bash
+sudo shutdown now
+```
+
+## Creating the ProxyVM
+
+Create an AppVM based on the TemplateVM you have just created. Set `sys-firewall` (or whatever FirewallVM you have connected to your `sys-net`) as the net qube. If you do not have such FirewallVM, use `sys-net` as the net qube. Next, go to the advanced tab and tick the `provides network access to other qubes` box.
+
+![Provides Network](/images/provides-network.png)
+
+Edit `/rw/config/rc.local` to workaround [issue 3803](https://github.com/mullvad/mullvadvpn-app/issues/3803):
+
+```bash
+echo "sleep 10 # Waiting a bit that Mullvad succeeds to establish connection
+/usr/lib/qubes/qubes-setup-dnat-to-ns" | sudo tee -a /rw/config/rc.local
+```
+
+You can now use this ProxyVM as the net qube for other qubes!
+
+## Notes
+
+With this current setup, the ProxyVM you have just created will be responsible for handling Firewall rules for the qubes behind it. This is not ideal, as this is still a fairly large VM, and there is a risk that Mullvad or some other apps may interfere with its firewall handling.
+
+Instead, I highly recommend that you [create a minimal Mirage FirewallVM](/posts/os/firewalling-with-mirageos-on-qubes-os/) and use it as a firewall **behind** the Mullvad ProxyVM. Other AppVMs then should use the Mirage Firewall as the net qube instead. This way, you can make sure that firewall rules are properly enforced.
+
+![MirageOS](/images/mirageos.png)

content/posts/qubes/Using Split GPG and Split SSH on Qubes OS.md

@@ -0,0 +1,86 @@
+---
+title: "Using Split GPG and Split SSH on Qubes OS"
+date: 2022-08-13
+tags: ['Operating Systems', 'Qubes OS', 'Security']
+author: Tommy
+---
+
+![Split GPG & SSH](/images/split-gpg-ssh.png)
+
+This post will go over setting up Split GPG, then setting up Split SSH with the same PGP keys. Effectively, we are emulating what you can do with a PGP smartcard on Qubes OS.
+
+## Split GPG
+
+Follow the official Qubes OS [documentation](https://www.qubes-os.org/doc/split-gpg/) to set this up.
+
+Note that if you already have a PGP key with a passphrase, you can remove it by installing `pinentry-gtk` to `vault`'s TemplateVM, then do `gpg2 --edit-key <key_id>` and `passwd` to set an empty passphrase. The default non-graphical pinentry will just make an infinite loop and will not allow you to set an empty passphrase.
+
+## Split SSH
+
+This part is based on the Qubes Community's [guide](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/split-ssh.md); however, I will deviate from it to use the PGP keys for SSH instead of generating a new key pair.
+
+### In `dom0`
+
+- Create `/etc/qubes-rpc/policy/qubes.SshAgent` with `@anyvm @anyvm ask,default_target=vault` as the content. Since the keys ar not passphrase protected, you should **not** set the policy to allow.
+
+### In `vault` AppVM
+- Add `enable-ssh-support` to the end of `~/.gnupg/gpg-agent.conf`
+- Get your keygrip with `gpg --with-keygrip -k`
+- Add your keygrip to the end of `~/.gnupg/sshconrol`
+
+![PGP Keygrip](/images/keygrip.png)
+
+### In `vault`'s TemplateVM
+
+- Create `/etc/qubes-rpc/qubes.SshAgent` with the following content:    
+```bash
+#!/bin/sh
+# Qubes App Split SSH Script
+
+# Activate GPG Agent and set the correct SSH socket
+export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
+gpgconf --launch gpg-agent
+
+# safeguard - Qubes notification bubble for each ssh request
+notify-send "[$(qubesdb-read /name)] SSH agent access from: $QREXEC_REMOTE_DOMAIN"
+
+# SSH connection
+socat - "UNIX-CONNECT:$SSH_AUTH_SOCK"
+
+```
+
+- Make it executable with `sudo chmod +x /etc/qubes-rpc/qubes.SshAgent`
+- Turn off the templateVM. If the `vault` VM is running, turn it off, then start it to update the VM's configuration.
+
+### In `ssh-client` AppVM
+
+- Add the following to the end of `/rw/config/rc.local`:
+```bash
+# SPLIT SSH CONFIGURATION >>>
+# replace "vault" with your AppVM name which stores the ssh private key(s)
+SSH_VAULT_VM="vault"
+
+if [ "$SSH_VAULT_VM" != "" ]; then
+  export SSH_SOCK="/home/user/.SSH_AGENT_$SSH_VAULT_VM"
+  rm -f "$SSH_SOCK"
+  sudo -u user /bin/sh -c "umask 177 && exec socat 'UNIX-LISTEN:$SSH_SOCK,fork' 'EXEC:qrexec-client-vm $SSH_VAULT_VM qubes.SshAgent'" &
+fi
+# <<< SPLIT SSH CONFIGURATION
+```
+
+- Add the following to the end of `~/bash.rc`:
+```bash
+# SPLIT SSH CONFIGURATION >>>
+# replace "vault" with your AppVM name which stores the ssh private key(s)
+SSH_VAULT_VM="vault"
+
+if [ "$SSH_VAULT_VM" != "" ]; then
+  export SSH_AUTH_SOCK="/home/user/.SSH_AGENT_$SSH_VAULT_VM"
+fi
+# <<< SPLIT SSH CONFIGURATION
+```
+
+- Restart `ssh-client` and confirm if it's working with `ssh-add -L`.
+
+### Limitations
+A malicious `ssh-client` AppVM can hold onto the ssh-agent connection for more than one use until it is shut down. While your private key is protected, a malicious actor with access to the AppVM can still abuse the ssh-agent to log into your servers.

content/posts/qubes/_index.md

@@ -0,0 +1,7 @@
+---
+title: Qubes OS
+ShowReadingTime: false
+ShowWordCount: false
+---
+
+A collection of posts about Qubes OS and related applications