Would appreciate anyone summarising the key differences here as I can't watch the video at the moment.
Linux folk are familiar with working with file descriptors--one just writes to stdout and leaves it to the caller to decide where that actually goes--so that was the example used but it seems like this sort of thing is done with other resources too.
It looks like a design that limits the ways programs can be surprising because they're not capable of doing anything that they weren't explicitly asked to do. Like, (I'm extrapolating here) they couldn't phone home all sneaky like because the only way for them to be able to do that is for the caller to hand them a phone.
It's got strong "dependency injection" vibes. I like it.
The main benefit is that kernel space is drastically smaller which means that the opportunity for a kernel-level exploit is minimal vs something like the Linux kernel that a single device exploit compromises your entire machine.
You don't need to give a process/component the “unrestricted network access capability” -- you could give it a capability to eg “have https access to this (sub)domain only” where the process wouldn't be able to change stuff like SSL certificates.
EDIT: and to be clear, fuchsia implements capabilities very well. Like, apart from low-level stuff, all capabilities are created by normal processes/components. So all sorts of fine-grained accesses can be created without touching the kernel. Note that in fuchsia a process that creates/provides a capability has no control on where/to who that capability will be available -- that's up to the system configuration to decide.
For many people it's just extra friction in search of a use case.
Maybe once those harms are all grown up, we'll find that fancier handcuffs for our software is worth a bit more than "just extra friction."
Also imagine you are trying to run a browser. It’s implicitly going to be able to perform arbitrary network access and there’s no way you can restrict it from phoning home asides from trying to play whackamole blocking access to specific subdomains you think are it’s phone home servers.
That’s why I said “semantic” capabilities aren’t a thing and I’m not aware of anyone who’s managed to propose a workable system.
Of course you can!
With capabilities you can tell a program: "if you want to communicate with the external world here's the only function you can use :
`void postToMySubDomainSlashWhatever(char* payload, size_t size)`
But don’t lose the perspective on the benefits of such an architecture. Considering the networking access example:
* If your process gets compromised it won’t be able to access the attacker’s C&C server. It wouldn’t have access to any other stuff that the process didn’t already have for that matter.
* You wouldn’t be able to use http. It would be https only.
* Your process wouldn’t need a lib to talk HTTP. It would just need to talk the IPC protocol (whose wire-format and related details are standardized in Fuchsia which allows for the binding code for (de)serialization to be auto-generated).
* You wouldn’t be able (for better or worse) to mess with SSL certificates, proxies, DNS resolution, etc.
Consider another example -- file access. Say your app wants to access a photo. It doesn’t have access to the filesystem nor to the user’s folders -- it only has access to, say, an “app framework services” capability (eg. services from an UI-capable OS like Android) whose one of the “sub-capabilities” is requesting a photo. When your app does that request the ‘system’ opens a file selection GUI for the user to pick a photo. Note that the photo picker GUI is running on a different process and your app doesn’t know and can’t access anything about it. All that matters is that your app will receive an opened file handle in the end. The opened file handle is a capability as well. The file handle would be ready-only and wouldn't need to actually exist in any file system. In this example, before handing the file descriptor to your app, the “system” (or whatever process is implementing the ‘photo-picking’ capability) could process the image to remove metadata, blur faces, offer the user to edit the image (and maybe actually save it to a persistent store), log that access for reviewing later, etc.
(We already have something kinda similar in Android, but the implementation is not from first principles, so it’s very complex and prone to issues (requires an obviously non-POSIX Android userspace using lots of security features from the Linux kernel to sort of implement a microkernel/services like architecture)).
EDIT: adding the detail that Fuchsia's IPC lang ecosystem has autogen features due to its standardization.
All I said was that capabilities don’t solve the spyware problem and they largely don’t. They help protect you write software that itself can’t be hijacked to become uncontrolled spyware due to a compromise but if I am selling you software with “malware” bundled you’re going to have a hard time isolating the functional and “malware” bits (malware here being defined as software against the users wishes and intents).
You’ve extolled the benefits of it and they’re great and I think I largely agree with all of that, but it’s completely irrelevant to my initial point that it’s not a silver bullet for the vendor intentionally bundling malware into the code they’re distributing.
Sure, a web browser that needs to open arbitrary network connections can be built to phone home. But nearly none of the components it’s built out of can. The image decoding and rendering libraries can’t touch the network, the rendering engine can’t touch the network, and nor can the dozens of other subcomponents it needs to work.
Your installed editor extensions can’t phone home even if the editor itself can. Or perhaps even the editor itself wouldn’t be able to, if extensions are installed out of band.
Your graphics driver vendor can’t phone home, your terminal can’t phone home, and on and on and on.
A solution doesn’t have to be perfect for it to be an improvement, so stop acting like it does.
Anyway, you’ve just proven my point with “install extensions out of band” - you’ve ceded that it’s a losing position technically and are arguing for alternative UX solutions. I’m not pretending it has to be perfect. Like I said, capabilities are great for creating a secure OS and writing more secure software more generally. But the threat model it’s protecting against is not software that phones home but against the size of the exploit opened up from a compromise.
Think about it this way, Android apps and iOS apps are largely sandboxed through a primitive capabilities system already, not super fine-grained capabilities but still the same concept. Would you care to claim that privacy and malware isn’t a problem on these systems or that the permissions model has meaningfully curtailed anything but the most egregious of problems?
Secondly, the editor also does it this way this because of reasons other than support within the OS because even with components it would need to design a capabilities model for extensions and a sandbox process to maintain the permissions - it’s much easier to just do the extensions in-process and not think about it.
The difference is in that every single one of those other operating systems, applications just have network access. By default. No capability needed. This would not be the case in an OS centered around capabilities.
Multi-platform software develops integration with local OS APIs all the time.
Like I said, your thinking is way too black and white. Your inability to see a different world doesn’t make one impossible to exist. What is even the point of thinking this way? Your entire mindset boils down to “nothing can ever be better”.
I’d ask you refrain from personal attacks. That isn’t a fair characterization of what I said. All I said is that capabilities fundamentally doesn’t solve the phone home problem in many real world cases. I also highlighted that there are very real economic forces that must be accounted for in terms of understanding why software is architected the way it is. And no, there’s very few applications that have a completely different architecture per major platform which is what we’re talking about with capabilities. That’s very different from abstracting some platform-specific APIs here and there.
But isn’t that exactly the same as MAC with default deny..? Different terms.
* Capability-centric design
* Single machine scope
* Tree of sandboxes
* Weaker inter-sandbox fault tolerance
* Standardized IPC system
* Model powers low-level OS features
* More detailed inputs/outputs from sandbox
* Configuration and building in separate files
* Sandboxes can encapsulate other sandboxes
If it’s anywhere close Google might be sat on a huge opportunity to tread the same ground while solving the ergonomic issues that NixOS has. (I’ve never been more happy with a distro, but I’ll admit it took me months to crack)
They are working on some components/layer to run things from Linux, but you would not expect all things built to work directly or as well as thing designed from the get-go for Fushia in mind.
I meant a little more in the way that software is packaged and run. My understanding is that theres a similar mechanism for storing and linking shared libraries that means multiple versions can go exist and be independently linked depending on the requirements of the calling package.