No, it has nothing in to do with NeXTSTEP. XPC was designed recently and for macOS/iOS. This is just that it was not designed with security in mind along this axis.

> On Windows land you have something similar

I'm still waiting to hear about a kernel-level exploit that starts with Visicalc or similar.

XNU, or more specifically the Mach part of it, also had some very questionable design choices that likely compounds the issue as it forces people to work around it in increasingly awkward ways. As Mach was conceived and mostly designed by an academic with no real world industry experience in shipping kernels.

I like ChromeOS' security model: Nail everything shut, but leave a Linux VM as a escape hatch.

> There's no security model for desktops that works well.

Don't you think that something which combines ideas from Firejail and Guix containers could be good enough?

For those who have not used Firejail, it is a sandbox that comes with default security profiles for most popular Linux binaries, so it's pretty unobtrusive. Say you want to run Firefox, Firejail limits access Firefox to ~/.mozilla and ~/Downloads by default. So, in case Firefox is compromised, attackers can't steal things from other $HOME directories like ~/.ssh.

On the other hand, Guix lets you launch ephemeral shells, like Nix, with any combination of packages. Unlike Nix, it provides a very convenient set of flags to sandbox the shell in terms of network, files, etc. This is handy for development tasks where you would like to have fine-grained capabilities.

>On the other hand, when Telegram asks you to share all your contacts and images with it, people do.

This is where Android shines with storage and contacts scopes. You can share an empty scope with the app and it will stop bugging you, and have access to nothing!

> There's no security model for desktops that works well.

Qubes OS works quite well, if you need security on desktop.

> There's no security model for desktops that works well.

> Like another commenter said iOS has no legacy cruft and could deliver the security model that made sense.

Yeah I just was wondering about this. In the presentation also Seatbelt is mentioned, I thought this was considered deprecated legacy since years. IIRC the last time I checked for sandboxing I basically couldn't find anything recent for the Application level

That's not fair. The sandbox was not the reason for WinRT/UWP's failure in the market. It was the mostly unfinished tablet UI that they half ported from their phone and told developers that was the future. They even copied Apple and threw in some half-baked store with it. There was no way Microsoft was going to become successful at it, especially when Apple couldn't even get developers excited about their own implementation.

Most desktop software needs to provide value for customers, or they would just build the web version of it. Being "native" isn't enough.

So, if you want to require that us developers run our stuff inside of sandboxes, that's fine. Just make sure the sandbox doesn't prevent our software from getting access to the same important desktop surfaces.

> developers that want to play there

That pun was superb btw

> That means throwing out a lot of code too. It's the cost to pay.

And likely, upsetting power users who want to run with all the safeties off.

It kind of sounds like you're advocating the type of security where the computer is secure against its owner, can't be programmed by its owner, doesn't support modifications to the OS, and so on. Is that right, or so you envision a highly secure system that can be controlled by its owner?

> All OSes in prod today need to be rebuilt from the ground up to be secure for the next century

Qubes OS solves this with hardware virtualization, which is really fast and secure.

Think again.

Barium-class downboats appear to be sinking your battleship! :^O

Depending on where it is in the product lifecycle, I've seen this extreme pushback against fixing symptomless bugs.

I was working on a project where someone thought to turn on tools for catching malloc errors (use past the end of allocated buffer, use after free &c.). The team that did this found bugs in their own code, of course, but also many from other teams.

I was there in the room as people went item-by-item litigating whether or not each bug should be fixed. Things like "sure this is use-after-free, but it's used immediately after the free and because of the struct offset, it can't corrupt the heap linked-list, so we won't fix it"

> The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old.

Yes, it requires a lot of time and patience. And I bet that the researcher has more reported vulnerabilities that he can't talk about and aren't fixed. He's been doing this for many years.

> I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP?

Apple is notorious for poor communication with security researchers... and with developers, and with everyone else. Apple also tends to patch vulnerabilities more slowly than, say, Google, and Apple frequently stiffs people on the security bounty.

> Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades.

This is kind of an empty reply. Of course Apple can try and has been trying. The question is whether they can do it successfully, and I would argue it hasn't been successful.

> It's been gradual enough that most end users haven't noticed

This is not true at all. Users have definitely noticed all of the permissions dialogs and other related settings.

SELinux can be part of the solution but it doesn’t solve the problem. The median Linux system is far behind the median Mac because while SELinux exists you still have to craft fine-grained policies and deal with all of the exceptions needed to have the system still be usable. This is more a function of budget than anything else.

> SELinux managed it

Not when you have SELINUX=disabled (rather than SELINUX=enforcing), which is what I've seen in most environments.

Personally I've had better experiences with AppArmour.

Complete different set of tradeoffs.

This is one of those situations where there is no good option, just the least worse option.

SE had mostly servers, depends on package vendors being altruistic, and people mostly just disabled it when it caused problems.

That is a very different set of assumptions and challenges than what Apple faces.

Usability. And/or good taste.

Can your grandma use SELinux? Delusional.

There's a [dead] reply that you may not see, but frankly I kind of agree with it: "Can your grandma use SELinux? Delusional." https://news.ycombinator.com/item?id=42087188

It really depends on your threat modeling and what you're concerned about. I agree, dual booting isn't ideal, but also, "dual booting Qubes and Ubuntu for gaming" cannot be any worse than "simply running everything on Ubuntu," as long as you don't believe Qubes is impervious to anything nasty in that configuration.

The main storage partitions are encrypted for Qubes (... or had better be, I guess you could avoid that, but why?), so the dual booting attack path would have to be through the boot partition, load something that can then compromise the install. It's a fairly specific sort of attack that, if someone's coming after you with that, it's probably a question of "How and when you're screwed, not if." But for general users, I think dual booting is an acceptable compromise. Just don't do much of anything in the other install!

I dual boot my laptop. There are a handful of things that are far easier to do in Ubuntu than Qubes (movies on a long flight, run a Windows VM to run particular software to talk to cars, and Minecraft for LAN parties). I'm aware of the risks, and don't consider them to be enough to remove the ability to do a few other things on one machine. I try not to have too large of piles of single purpose computers these days...

I write code, yes. I'll just spin up a development VM as needed, things work fine. I don't use Docker, but as long as you're not using the hardware virtualized modes, it should work just fine on namespaces. Every VM is running a full featured Linux kernel. There's just not nested virtualization support, which I'm totally fine with, because nested virtualization on x86 is a rather complex mess to get right.

The main thing you lose is GPU acceleration. I don't particularly care.

Matrix bridges solve a lot of this problem, though... aren't really reducing complexity at all ends of the system. It does radically reduce end user app complexity, though.

I've been hosting a Matrix homeserver for... oh, 4-5 years, now, and I have bridges installed for my use and a few other people who use it that bridge Signal, Google Chat, Facebook Messenger, and maybe one or two other services into Matrix - so I almost never have to bother with the other clients, I just use a Matrix client everywhere. There are the occasional quirks you have to deal with, most of which are solved by upgrading your bridge (and the new bridges are a lot easier to deal with than the older ones).

As people decide to go Matrix-native, I can talk to them that way as well.

That said, as far as non-Matrix options go, Signal seems to be a fairly common one and easy enough to get people to switch to.

Fair enough, good point and good catch. Edited my reply just in case this gets lost in the firehose of 32 comments ;)