And that's before you consider things like Docker, which will let you run linux software just about anywhere including windows, mac, BSD, etc. On the desktop we have things like Snaps, Flatpack, etc. Also consider Steam running games made for windows on Arch Linux, and Apple running software compiled for Intel on ARM. Windows 11 will run Android applications apparently. And of course WASM is the next level in portable executables.
The OS as a control point for where software can be installed and used is increasingly less relevant. It's increasingly about controlling the application stores and maximizing their reach rather than the OS platforms. Mobile is actually lagging behind these trends a bit; mostly because of draconian app store policies discouraging/forbidding anything that is "not native".
It will be interesting to see if Fuchsia will get a lot of adoption outside of Google. I'm very skeptical about their ability to convince others to use this. Even their strategy around Fuchsia remains murky. E.g. their whole IOT strategy resembles what they are doing with messaging in terms of quickly abandoned things that they announce with a lot of fanfare every year. One of these train wrecks is Nest, which they picked as a niche player guinea pig for the first commercial rollout of Fuchsia. I doubt it will move the needle for Nest. Or for Fuchsia.
I don't really know how does it work in Fuchsia but AFAIK it is supposed to implement capability-based access control giving the apps access only to what and when they really are meant to access (rather than everything the user who launched them is eligible to access). I believe constraining native apps written for traditional OSes this way may not be trivial.
Fuchsia's capabilities mechanism are strictly superior. There has been, over various android version, many fixes to "leaks" of information due to the SELinux configuration not being comprehensive enough, and linux being default open when it comes to capabilities. In contrast, Fuchsia is default closed, so if you don't ask for the permission to do something, you can't.
I distinctly remember ad companies using various tricks like reading /proc and the like to try and get information about what applications are running on a phone and what servers they are communicating with without asking for perms (it's fixed now, but it used to be a thing years ago). This is the kind of stuff that fuchsia should, in theory, prevent.
Yes, this is a huge problem. I wish Google would enforce zero-tolerance policy against apps misusing this mechanism and asking for permissions they don't really need for fulfilling their actual function.
Capability-based security has been available in FreeBSD for a decade now: https://en.m.wikipedia.org/wiki/Capsicum_(Unix) The real problem at the moment is not the OS, it’s the applications written or modified to use it.
> it loses all permissions normally associated with its controlling user, with the exception of "capabilities" it already has in the form of file descriptors.
What if we want to grant an app already running a new capability on the fly? E.g. I imagine a case of user opening a file in a GUI app as an OS-level file selection dialog getting invoked (provided the app already has a capability to invoke it, as by the manifest) and producing a capability for the app to access the file the user choosse in an explicitly specified (RO or R/W) mode.
It cannot be forced to enter, no. It could be executed in capability mode, though, except you would have to give up dynamic linking, for obvious reasons.
As for granting new capabilities - you can pass capabilities from the outside; otherwise the whole mechanism would make no sense :-) In Capsicum case, capabilities are file descriptors, and you pass them the usual way, over Unix sockets.
- Solaris LX-branded zones;
- Microsoft WSL1;
- Google gVisor;
- Amazon Firecracker.
None of above done anything groundbreaking (other than ditching GPL). Why would you think LX-branded Fuchsia would?