Breaking all macOS security layers with a single vulnerability

In principle you could do something similar with the Mac/iOS sandbox by starting a process with a compute only sandbox, and then provide it with specific sandbox entitlements (from the parent) which includes specific file systems, however they still in principle can see a full version of the fs.

And yeah, any OS that isn’t completely new is burdened with support for old apps, but then iOS which used its newness to have a stronger base security model is constantly beaten up for that model.

You could quarantine your old applications to their own individual VMs, while newer programs can make use of your shiny new security features?

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.

Contrarily, that makes me happy because if that happens we are really going to lose what little computing freedom we have left, as it will only make the walled garden silos even stronger.

I have a tiny bit of hope that they'll eventually be able to replace desktop OSes through virtualization. It's actually what I long thought Apple would do with iPad OS (why else put in an M1?).

Every other kind of interaction between seperate applications can be blocked without breaking much functionality. And you can limit breakage further by running all 'legacy' applications in the same silo, and only running new applications disconnected from eachother.

And than, at some point Google's Fuchsia will also surface in mainstream likely.

Both systems will bring capability-security. (You know, almost like seL4, only less secure). A technology that wasn't used until now, even it's available for almost 50 years, and would solve almost all security problems of computers. We could have had that in fact directly supported by hardware almost four decades ago… But the market didn't like that.

The problem is that there is and won't be any progress in computer technology. It's like that since at least one hundred years. We're buried in the von Neumann local "optimum" since than… As long as this does not change we're doomed to have crappy, inefficient, and insecure computers. The invisible hand will just prevent any progress until forever. (OK, our future AI-Overlords could change that possibly).

But who cares about the status quo? The market insists on it. So any attempt at resistance is therefore futile.

___

Please excuse the slight amounts of sarcasm. I just couldn't hold back.

And seriously: There may be some jokes hidden in here. If you try you'll recognize one or two of them, I bet… :-D

Qubes is sandboxing at a machine level by putting every application set into it's own O/S. Is that in any way clean or ideal? Not at all. But it's necessary if you don't trust your own O/S not to have been compromised by the software running inside it.

I get the arguments against centralised software distribution - it encourages monopolistic behaviour and removes user freedom - but it does at least make a problem of this nature fixable if you can enforce compliance to breaking changes at distribution time.

I'd like to think a new layer could be added to Linux or BSD that would marshall this kind of compliance centrally without deliberately conflating payment into it, but I've no idea how you'd get widespread adoption of something like that even if you could organise to implement it. You'd also likely need to implement code-signing everywhere which was such a challenge in the past that (at least in the Linux kernel) it was abandoned.

A similar model to how domain registration works for white-listing might make sense here, in that it's not centralised - but it's not fully decentralised either - and at some point there needs to be a process to onboard new authorities who everyone needs to trust, at which point it's a slippery slope to self-certification.

I don't think that's the case though. Microsoft overhauled the entire security post of windows during Vista. It wasn't a good OS when it came out, but Windows is much better for it.

But yes, if you're going to start from the ground up, you're going to lose a bunch of functionality. Not only due to the nature of rewrites, but also because of "what new limitations does the security model imply"?

Hiding something with ROT-13 just 'so it doesn't show up in grep' is a bad idea.

> This vulnerability will therefore be present for as long as there is backwards compatibility with older macOS applications!

I'm still remember this problem happen to Atom, cause me a lot of data loss, in the end, apps will have their way of store temporary state file, without relying on macOS's build-in state, like office and all other modern code editor.

Clearly, you're not in the business of selling high performance, modern computers with 8GB of RAM...

Apple's base amounts of RAM are stingy at best.

I do use it, frequently. So frequently that I have designated Force Quit as my “turn it off and on again” mechanism for nearly everything for years. Granted my daily usage app catalogue is minimal, and I agree some aspects of normal behavior are less predictable than one might wish (the article covers those). So I respectfully defer to your experience and decision not to use it. In my experience it’s as reliable as Quit or Shutdown for every app I use, and sometimes more reliable for misbehaving apps which have custom state saving functionality. VSCode in particular comes to mind, it restores undo/redo history when force quit and falling back to built in system behavior but comes up with no history if I so much as agree to a software update.

> Honestly what is the benefit? A computer is off, on, or sleeping.

The benefit is that, excepting certain details most use cases rarely encounter, the computer and apps running on it have only one state instead of three: resume where you left off. For active multitasking, that means waiting for volatile storage. For “App Nap”, Force Quit, and crashes that means waiting for non-volatile storage. For reboots and logins that means waiting for a bunch of other apps and services to resume. But if the app uses the functionality even semi-faithfully, you’re only waiting for it to become responsive again, then it resumes as if it were in the same state you left it. Regardless of whether your computer or even your app was on, off, or sleeping.

Again, not saying it’ll work that way for you and I’ll defer to your experience. But if you want to know how other people benefit from it, my experience is I can kill almost any process on my computer or even force reboot, and the only consequence before I resume what I was working on is how long I might have to wait.

The last thing I want is for all that crap to load back up on restart all at once.

Turns out, he had a lot of programs running despite not having a document open, and that "reopen window" function was causing them to all reload on startup. Browser, word processor, tax software, whatever else. All on his aging Mac that I'm fairly sure only has 4 GB of RAM.

In the original Unix security model, there was no security concern with this (except maybe for chroot environments): it didn't allow a process to do something it couldn't otherwise do, since all processes owned by a uid had exactly the same rights. Now that we've started sandboxing user processes in various ways on macOS and Linux, that's no longer the case, and we suddenly need to crack down on useful tools like strace and gdb.

Unix security model was never meant to protect user processes between themselves, it only meant to protect system from user apps, which is a bad model these days, where basically every device has a single user, and the real threat is user apps hacking and stealing each others data.

This is completely wrong. Apple makes very little of its revenue from advertising. Their cash cow customers are iPhone users.