>Changing a security model that has been used for decades to a more restrictive model is difficult, especially in something as complicated as macOS. Attaching debuggers is just one example, there are many similar techniques that could be used to inject code into a different process. Apple has squashed many of these techniques, but many other ones are likely still undiscovered.

> Aside from Apple’s own code, these vulnerabilities could also occur in third-party software. It’s quite common to find a process injection vulnerability in a specific application, which means that the permissions (TCC permissions and entitlements) of that application are up for grabs for all other processes. Getting those fixed is a difficult process, because many third-party developers are not familiar with this new security model. Reporting these vulnerabilities often requires fully explaining this new model! Especially Electron applications are infamous for being easy to inject into, as it is possible to replace their JavaScript files without invalidating the code signature.

It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten!

Mobile OSes were a good break off point as far as security goes but that came with a lot of functionality sacrifice.

Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft.

> Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft.

I'm trying to encourage as many people as I can to run it, or at least play with it for some while to gain familiarity with it. Properly applied, I think it does add quite a bit of useful practical security... though it's not going to automatically solve all problems. I like the silos of compromise, at least, and you can do high risk things (like "anything web") in disposable VMs that reset on VM power cycle.

My only major concern with Qubes is that I've not decided if it's weird and niche enough to be mostly left alone by the 0day markets, or if it's a super high priority, high value target to attack because of the type of people who are likely to use it. I'd like to see an ARM port of it, because Xen on ARM is quite a bit simpler than Xen on x86, but the hardware to run that doesn't quite exist yet. Maybe with the RK3588...

The fundamental problem here is that software developers (and I'm guilty here too, as much as anyone in that industry) tend to view complexity as a one way ratchet function - add features. Add features. Add features. Add knobs. And when it comes crashing down around your ears, "add security" (in the form of sandboxes, or process isolation, or... https://xkcd.com/2044/ applies here).

And then it turns out that "adding complexity to solve problems created by complexity" isn't a strategy with a great long term success rate.

I'm slightly encouraged by Apple admitting, as clearly as they ever admit anything, that this strategy isn't working - with their Lockdown mode, that's "only for people with the most extreme threats, blah blah blah," and I'd expect anyone in the security or software industry to turn that on basically as soon as they get iOS 16 and not look back. Or install the beta to give that option.

I have tried the QubesOS and boy does it bring back memories of Windows being called Pentium to 286 converter. It is slow as molasses on hardware where even Windows 10 and Gnome are both fast and to make it usable you have to keep relaxing the security to the point where it is probably less secure than regular OS. And don't even bother if you have to use scaling other than 100%, sure you can scale the DOM0 but the rest of the VMs are not scaled and there is no documentation on how to do it. What we need are simple sandboxes that isolate GUI applications into chroot environment and keep them away from other applications and documents.

> It is slow as molasses on hardware where even Windows 10 and Gnome are both fast...

I haven't had that problem. There's no GPU acceleration, so anything heavy on the GPU is a problem, but in terms of general use, I don't find it slower than Linux on the iron.

> and to make it usable you have to keep relaxing the security to the point where it is probably less secure than regular OS.

How so? What settings? I don't run with a USB Qube all the time for just my HID devices, but I light it up when I'm doing anything else on USB. I haven't had issues with having to turn down a bunch of security settings either.

> And don't even bother if you have to use scaling other than 100%, sure you can scale the DOM0 but the rest of the VMs are not scaled and there is no documentation on how to do it.

Yes there is. https://github.com/Qubes-Community/Contents/blob/master/docs...

> What we need are simple sandboxes that isolate GUI applications into chroot environment and keep them away from other applications and documents.

The history of local root exploits ("Cheap and easy!") would argue that doing such a thing and relying on the kernel is just security theater.

>The history of local root exploits ("Cheap and easy!") would argue that doing such a thing and relying on the kernel is just security theater.

it may not be perfect but surely its better than nothing. it wouldn't protect you from a sophisticated nation state attacker, but most people don't have that in their threat model. surely it would be good enough to prevent google chrome from snooping through your home directory and other such things.

> surely it would be good enough to prevent google chrome from snooping through your home directory and other such things.

You want firejail, I think; this is one of its headline features. (Or possibly bubblewrap.)

Please do not use firejail. See this issue page: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12635

Bubblejail is an acceptable alternative https://github.com/igo95862/bubblejail