I find people who agree with me for the wrong reasons to be more problematic than people who simply disagree with me. After writing a lot about why free software is important, I needed to clarify that there are good and bad reasons for supporting it.
You can audit the security of proprietary software quite thoroughly; source code isn’t a necessary or sufficient precondition for a particular software implementation to be considered secure.
Windows Enterprise and macOS are ahead of Linux’s exploit mitigations. Madaidan wasn’t claiming that Windows and macOS are the right OSes for you, or that Linux is too insecure for it to be a good fit for your threat model; he was only claiming that Windows and macOS have stronger defenses available.
QubesOS would definitely give Windows and macOS a run for their money, if you use it correctly. Ultimately, Fuchsia is probably going to eat their lunch security-wise; its capabilities system is incredibly well done and its controls over dynamic code execution put it even ahead of Android. I’d be interested in seeing Zircon- or Fuchsia-based distros in the future.
When it comes to privacy: I fully agree that the default settings of Windows, macOS, Chrome, and others are really bad. And I don’t think “but it’s configurable” excuses them: https://pleroma.envs.net/notice/AB6w0HTyU9KiUX7dsu
Here’s an exhaustive list of the proprietary software on my machine:
That’s it. I don’t even have proprietary drivers. I’m strongly against proprietary software on ideological grounds. If you want to know more about my setup, I’ve made my dotfiles available.
Servers use Linux. Home users needing security does not arise from OSes being insecure, but user being weak link. https://pointieststick.com/2021/11/29/who-is-the-target-user/ Also, this is contradicted by…
QubesOS is based on Linux.
Here are two HN discussions that highlights madaidan’s issues. You can read them to understand his whole game.
https://news.ycombinator.com/item?id=26954225 (10 comments)
https://news.ycombinator.com/item?id=25590079 (295 comments)
This is a defeatist attitude and meaningless excuse. Adding more closed source software and hardware stacks mean extra attack surface. And extra attack surface should be avoided first, mitigated second.
The server, desktop, and mobile computing models are all quite different. The traditional desktop model involves giving programs the same user privileges and giving them free reign over all a user’s data; the server model splits programs into different unprivileged users isolated from each other, with one admin account configuring everything; the mobile model gives programs private storage and ensures that programs can’t read each others’ data and need permission to read shared storage. Each has unique tradeoffs.
macOS has been adopting safeguards to sandbox programs with fewer privileges than what’s available to a user account; Windows has been lagging behind but has made some progress (I’m less familiar with the Windows side of this). On Linux, all modern user-friendly attempts to bring sandboxing to the desktop (Flatpak and Snap are what I’m thinking of) allow programs opt into sandboxing. The OS doesn’t force all programs to run with minimum privileges by default having users control escalating user-level privileges; if you
chmod +xa file, it gets all user-level privileges by default. Windows is…somewhat similar in this regard, I admit. But Windows’ sandboxing options–UXP and the Windows Sandbox–are more airtight than Flatpak (I’m more familiar with Flatpak than Snap, as I have some unrelated fundamental disagreements with Snap’s design).I think Flatpak has the potential to improve a lot: it can make existing permissions enabled at run-time so that filesystem-wide sandboxing only gets enabled when a program tries to bypass a portal (most of the “filesystem=*” apps can work well without it, and some only need it for certain tasks), and the current seccomp filter can be made a “privileged execution” permission with the default filters offering fine-grained ioctl filtering and toggleable W^X + W!->X enforcement. The versions of JavaScriptCore, GJS, Electron, Java, and LuaJIT used by runtimes and apps can be patched to run in JITless mode unless e.g. an envvar for “privileged execution” is detected. I’ve voiced some of these suggestions to the devs before.
My favorite (and current) distro is Fedora. If Flatpak makes these improvements, Fedora lands FS-verity in Fedora 37, Fedora lands dm-verity in Silverblue/Kinoite, and we get some implementation of verified boot that actually lets users control the signing key: I personally wouldn’t consider Fedora “insecure” anymore. Though I’d still find it to be a bit problematic because of Systemd. I wasn’t convinced by Madaidan’s brief criticisms of Systemd; I prefer this series of posts that outlines issues in Systemd’s design and shows how past exploits could have been proactively (instead of reactively) avoided:
Systemd exposes nice functionality and I genuinely enjoy using it, but its underlying architecture doesn’t provide a lot of protections against itself. The reason I bring it up when distros like Alpine and Gentoo exist is that the distro I currently think best combines the traditional desktop model with some hardening–Fedora Silverblue/Kinoite–uses it.
QubesOS is based on Linux, but it isn’t in the same category as a traditional desktop Linux distribution. Like Android and ChromeOS, it significantly alters the desktop model by compartmentalizing everything into Xen hypervisors. I brought it up to show how it’s possible to “make Linux secure” but in doing so you’d deviate heavily from a standard distribution. Although Qubes is based on Linux, its devs feel more comfortable calling it a “Xen distribution” to highlight its differences from other Linux distributions.
I only brought this up in response to the bad-faith argument you previously made:
I don’t use any closed-sourced tools on my personal machine beyone hardware support, emulated games, and webapps I have to run for online classes. Since you seem to be arguing in bad faith, I don’t think I’ll engage further. Best of luck.
And this is exactly what I have been saying since the past few replies. There is no one threat model for all systems and users. Madaidan, who you quote, however exactly tells us there is zero room for nuance, hence the multiple links I shared to give you room for processing more opinions.
To him, somehow Linux is bad because use of unsafe C language and monolithic kernel, but Windows and MacOS also have monolithic kernels and get excused. More CVEs (threat levels of each CVE completely ignored) instead of being proof of maturity, become proof of worse security. You basically linked and believe in what is known well as a piece of toilet paper blog among security enthusiasts that are not GRSecurity or such GrapheneOS community related grifters.
It seems you are fairly stubborn in your beliefs. If critical thinking is bad faith argumentation, then I will disengage as well.
P.S. I am a CS grad that created r/privatelife and teaches OPSEC.