Earlier quoted context omitted.
Bubblewrap isn't a sandboxing architecture, so no. Go look at how Apple designed the macOS/iOS security system and you'll see that a Bubblewrap like tool is only. small portion of it.
Linux in-general is a small portion of the Darwin architecture. One is a monolithic kernel, the other has microkernel IPC security to consider. Are there any glaring limitations in Bubblewrap you'd like to point out, or are we having the Tannenbaum argument all over again?
On Darwin-based systems you can take a binary from anywhere. Downloaded into $HOME, found in /Applications, on a USB stick, network drive, app store run by Apple, app store run internal to your enterprise, doesn't matter. When you run it, the kernel computes an unforgeable identity for that program.
That identity is then used for all sorts of things. It's used to:
1. Stop other apps tampering with the app's files or address space.
2. Let users grant permissions to that app via normal UI interactions. Not just to files but for anything you see in the privacy section of Settings.
3. Allow the app to upgrade itself while keeping its permissions. This doesn't require the app to use any specific package manager or update mechanism, the kernel doesn't care.
4. Allow you to run multiple versions of the app, while keeping its permissions.
5. Block the app if it's malware and make the block actually stick i.e. polymorphic code doesn't help.
6. Do an ahead of time virus scan on Apple's servers, so you get the benefits of antivirus without needing to run resource piggy scanners locally that trash performance.
7. Give the app a private file space that's protected from all other apps, where it can store configs, caches and other sensitive files. So if someone does run malware, it's very limited in how much tampering it can do.
8. Nothing depends on escalating to root, or any admin user, at any point.
Linux has a much weaker system, it's nearly non-existent.
1. Programs are identified based on where their binaries are, not what their binaries are. This is totally wrong and creates a lot of problems, e.g. the same program run from $HOME vs /usr is perceived as being a totally different app by the OS.
2. Programs aren't run under bubblewrap by default in any distro I've heard of. Indeed they can't be because the kernel doesn't have any support for this.
3. Bubblewrap isn't integrated with ELF so there's no way for a binary to declare what permissions it needs. Contrast with: `codesign --display --entitlements :- /Applications/Microsoft\ Word.app | xmllint --format -` which tells you what permissions Word has when it runs.
4. Desktop environments struggle to implement the PowerBox pattern macOS relies on so much, because desktop APIs are too fragmented on Linux and most common apps ignore them in favour of rolling their own equivalents. So bubblewrap by itself can't make sandboxing transparent. FlatPak is trying to implement a PowerBox design with portals, but it's obviously a layer above Bubblewrap alone.