[Gigachad]

I don't think privacy is such a simple scale like this. I actually trust my macbook to be more secure than my Linux desktop. Apple has spent orders of magnitude more securing this device, while my Linux desktop setup is mostly only ensured to be generally working.

If anyone with the smallest amount of skill had physical access to my desktop, they could replace the bootloader with a malicious one and get everything when I next log in. While my macbook is secured against basically everyone but top tier federal agents. If I left my macbook in a hotel room, I can reasonably expect it has not been tampered with.

There doesn't seem to be any real version of SIP on Linux. Basically every program I run requires full access to everything. Flatpak is sort of tightening things up but it still has a long way to go to close all the loose ends.

So while I might have more control over my linux machine, I still trust my macbook more.

[smoldesu]

Out-of-box, you're generally right. "Hacking" the average Linux user with Secure Boot disabled and a default GRUB configuration with unencrypted ext4 root is like taking candy from a baby.

It does beg the question of which system can be more secure, though. Apple has a decently high bar out-of-box, but they could certainly do more to make MacOS a trustless ecosystem. The simple fact that all of MacOS is basically unaccountable from a programming perspective is both a security flaw and a privacy concern. Whereas a public codebase like Linux receives constant intersectional scrutiny, closed systems like MacOS can't have that same attention. Non-transparent codebases cut both ways: they can hide embarassing bugs from people reading the source, but it can also protect zero-days and backdoors that would have otherwise been identified and fixed. Transparent systems only seek a ground truth.

So... it's a toss-up. I wouldn't put my life on the line if I was a political dissident considering a Macbook, but Joe Shmoe and his wedding photo editing business should have all the security it needs.

[kaba0]

GNU Linux desktop can’t be made more secure than a Mac in my opinion, without having to rewrite the whole thing to the point where calling it general linux desktop is a stretch. But this is not an OS property - if one would install Android, then the security would improve severalfold, likely better than OSX (mobile OSs are much more modern and security oriented). The reason is that the old-school UNIX permission system is way too crude. The minimum is to run every process under a new user, so that its permissions would even start to make sense. SELinux is also important, as well as secure IPC. Android has all that solved.

GrapheneOS on sufficiently secure hardware (! Unfortunately open-source laptops are very bad in this category), which has to be a Pixel for now trades blows with iphones.

[Gigachad]

The Linux security model was designed for a time when you had multiple humans sharing one machine, and every program either came from the OS, or was sourced from a reputable origin. It's almost useless in the current landscape. Some efforts like Flatpak, Wayland, Pipewire, and immutable OSs are starting to improve things, but it still seems like we are years away from having the level of security MacOS had a long time ago.

And I just can't see how any security measure which requires hardware can come to Linux desktop.

[smoldesu]

> And I just can't see how any security measure which requires hardware can come to Linux desktop.

Why? TPM works just fine. Secure Boot is perfectly usable on most OSes. Hell, even fprintd supports biometric authentication if you're a weirdo. Nothing inherently stops this stuff from being made, certainly not the kernel.

All hardware-based security measures will probably never be supported by Linux, but if your benchmark for disbelief is "any" then boy have I got a boat to sell you!

[saagarjha]

> Whereas a public codebase like Linux receives constant intersectional scrutiny, closed systems like MacOS can't have that same attention.

This is not true; Apple’s OSes get plenty of scrutiny by various groups looking to fix (and break!) its software defenses.

[smoldesu]

It's not the same. There are definitely people who try to exploit both OSes, but the conversation around securing them couldn't be more different. MacOS is developed in the "Cathedral" style - closed source, with a small group of contributors who assume responsibility for everything (including security response). Linux is developed in the "Bazaar" style, with patches being freely distributed and incrementally contributed by the community for each release. This represents a fundamental change in how security is handled; Linux can merge a fix as soon as it's available and passes review. Mac issues must be reported by a user, passed to an Apple engineer, located in the codebase, fixed, and then reviewed before it can make it into a Rapid Security Response patch. Apple's system is less transparent, often slower, and overall more convoluted than developers and users pointing to the spot that's broken.

[saagarjha]

I want things to work this way, but often they do not. Often what happens on the Linux side is that the security patch, if any, gets silently put into the tree without disclosing that it's a security patch, and downstream never pulls it in. There have been numerous instances of kernel maintainers asking people to water down their commit messages so they don't sound as bad as they are :/

This doesn't mean Apple does everything right, of course, but the situation on the other side frequently sucks too even though it nominally should not. And given various choices in their ecosystem (lack of fragmentation, for example) they can and do end up with a better security story in some areas.

[smoldesu]

Definitely, there are pros and cons to each process. They are markedly different, though - Apple wants secrecy, whereas Linux demands transparency. Sometimes patches are rejected or ignored, but transparency is never compromised. This gives insight into how patches are accepted or rejected (eg. the Paragon NTFS), information that isn't public in Apple's process. The separation of users and "blessed" developers remains an enormous roadblock to effectively scrutinizing and quickly fixing Apple's software platforms. It offers some protection, too, but it is a night-and-day difference to how things are handled in the Linux world, dysfunction and all.

[Gigachad]

I'm not sure if the MacOS codebase gets as much review as Linux, but what makes MacOS more secure is that they utilize multiple layers of security. Finding a bug in a single component is often not enough. Which is why even after countless bugs found in macos and ios, we never see things like the secure enclave and encryption keys compromised, because they are layered out and unaffected by bugs in the OS.

We are at the point where being bug free is impossible and patching after discovery is not good enough. Secure designs must protect against undiscovered bugs.

[saagarjha]

The Secure Enclave has been compromised in the past: https://raw.githubusercontent.com/windknown/presentations/ma...

[smoldesu]

You could custom-build a special version of MacOS that runs entirely in userspace, but unfortunately it would never be as secure as a properly-configured Linux system. The default on MacOS is a venerable effort, and a powerful standard to enforce across an entire line of devices. Apple does not give the user enough control to protect them against Apple themselves, though.

There are certainly security and convenience scenarios where MacOS is hard to beat, but no trust-based system can ever be the final say in security.

[scarface_74]

Yes and after that “constant instersectional security” there was a multi year OpenSSL bug in Linux.

[smoldesu]

Also the multi-year MacOS telemetry decryption exploit: https://www.cve.org/CVERecord?id=CVE-2011-0014

Classic case of Apache/BSD dual licensing there. Hopefully people learn their lesson and write less software like this in the future, but...

[kaba0]

Yeah, even a package install, or npm invocation could easily install a keylogger with full network access, or go over the file system and encrypt it.