I’m aware the head Dev of grapheneos can be prickly, but the format and tone of this post is terrible.

What is it exactly you’re upset about here?

Questionable behavior sure, but could you provide a technical explanation as to why the information presented on madaidans-insecurities, etc. is problematic?

To preface: I don’t hate (desktop) Linux, in fact I love it. It is all I use an all I will probably ever use (unless somehow RedoxOS becomes usable lol but even then probably not). Linux is great and I spend most of my time (in no particular order) using it while tinkering, browsing, gaming, doing work, and just having fun. It is precisely because I love Linux that it pains me that people shutdown immediately when they hear any criticism of Linux (and by extension any other of their fav open source projects). It is fine to critique projects, especially when they claim to be “privacy/security focused”. That phrase is so broad and heavily diluted by over use. What does it mean to be security focused?

(My response uses somewhat technical language. I am not a troll and I am not trying to be mean. I am sorry if I come across as arogant)

The Linux kernel has so, so, so many (security) features, such as namespaces, landlock, SELinux/AppArmor, chroot, seccomp, ptrace, encryption, KVM, etc. Then there is libc, malloc, firewalls, Wayland, init system, so many different components. But how much of that is being configured/used in everyday Desktop distros to improve security?

What is actually wrong about the Linux hardening guide? Linux Desktop lacks a real threat model and it is trivial for any run app/script/binary executable to establish persistence, steal passwords, exfiltrate data, preload malicious binaries, escalate privileges, etc etc etc. Desktop Linux is insecure, period. The fact that Linux gives running apps so much information/access makes attacking it very easy.

For example, I could make a simple script that when run:

• Installs itself at $HOME/.local/bin/sudo
• Changes the $PATH (for example in ~/.bashrc ~/.profile) to prefer binaries in $HOME/.local/bin
• Wait till the user runs a command as sudo (which runs the malicious script), stealing the password and passing the command to the legitimate ‘sudo’ (/usr/bin/sudo).
• After this happens remove the evidence and create a systemd service file with a generic name (as to blend in with the hundred real services) that allows me to remotely control the system whenever.

“But if it is just a script, cant I check it before running?” Could be an obfuscated binary. “What if I check ~/.local/bin?” Could just as easily be /tmp or buried in ~/.cache somewhere. “What if I check the $PATH variable?” I could use an LD_PRELOAD attack instead. “What if I just only run trusted apps?” Are you sure you can trust everything you run? Is everything you run OSS? Does your developer sign updates (most use GPG, see https://gpg.fail/ for why this is bad) and have reproducible builds? What if they are hacked? What if a dependency they use is hacked?

One of the easiest examples of an untrusted app that people run all the time is video games. They are often proprietary, humongous, and require device/hardware access. Effectively impossible to audit.

And that is just a simple and straight forward privilege escalation attack to establish persistence. Instead of doing anything suspicious, the script could just exfiltrate data, such as app data, or system info (like package/kernel versions, OS name/version) to make a targeted attack easily. The malicious program could just create a systemd user service, which doesnt require root, and runs at boot with target network to establish persistence.

The only coherent threat model is to treat all apps as if they are malicious, which is what browsers (and to a weaker degree what Android/iOS) do. Websites are effectively untrusted apps, and browsers are designed to run untrusted code.

And that isn’t even getting into all of the information obtainable from from the /proc, /sys, and /dev filesystems.

Flatpak and Snap are cool because they provide basic application sandboxing, but they aren’t designed to run untrusted applications (not their threat model scope). Flatpaks/Snaps declare their own permissions (with few exceptions), so a malicious app could just have a different manifest. Kernel vulnerabilities are still a problem because sandboxed apps share the same kernel. Permissions for these apps arent granular and many often requested permissions severely weaken the sandbox (eg. Lutris Flatpak needs device=all for gamepads to work, and also has full filesystem read/write access). Ideally, dangerous permissions are designed to limit the impact/likelyhood of a sandbox break. People hate Snapd (and for good reason), but it has a much better permission systems (way more targeted and specific permissions minimizing the scope for specific use-cases) and can request the user to allow dangerous permissions at runtime (eg. Zoom wants access to Microphone shows an on-screen pop-up). There is also the problem that these sandboxes are written in memory unsafe languages and don’t use hardened memory allocators (eg. mimalloc-secure, hardened-malloc, malloc-ng) though to be “fair” neither do practically any Linux distros.

Check out Kicksecure/Whonix and Secureblue for some of the hardening they do, but keep in mind none of them have or can fix the structural/cultural issues that continue to keep Linux behind curve when it comes to OS security. Any examples I have gave has a dozen others that will go unspoken. Check out Syd for information a real-world Linux sandboxing and exploit protection.

OS security is complicated. But ignoring the facts, burying your head in the sand, does nothing but stop you from expanding your knowledge and educating others. If we dont address these problems know, before the inevitable death of Windows, Linux Desktop adoption will be painful and malware will be plentiful.