5 ms·

It seems like Fuchsia components have less that they can assume about their environment and require the caller to be more explicit about what the component can

It seems like Fuchsia components have less that they can assume about their environment and require the caller to be more explicit about what the component can do ("capabilities"). So for instance a docker container might just decide--without the user's say-so--that it wants to write a debug log file to /foo/bar/baz and then it would be up to the user to go find that file if they care. By contrast a Fuchsia component would not by default have the capability to write anywhere, so the user would have to pass in a handle that says "write your logs to this place" if they wanted logs to exist at all. 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.

vlovich123 2y ago
Sure, but it is allowed, at least as far as I understand, to phone home if it otherwise needs network access. In practice it’s really hard to prevent unauthorized semantic network access once you allow any network access. 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.
- bestorworse 2y ago
  The joy of having a properly implemented capability system is that, well, you can create arbitrary capabilities. 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.
  - dekhn 2y ago
    In my experience lots of folks simply won't work with capability systems no matter how good the implementation is or whatever level of security and configuration granularity is provided. For many people it's just extra friction in search of a use case.
    - surajrmal 2y ago
      It makes testing a lot easier honestly. Also keep in mind that mobile apps and web apps are fairly capability oriented these days, so I wouldn't say no one will work with it...
    - onjectic 2y ago
      I am curious what your experience is with capability based security? They are still incredibly niche(unfortunately) so I’ve never had a chance to work with one at a job.
    - __MatrixMan__ 2y ago
      I'm just hearing about capability systems today, so your experience is undoubtedly richer than mine, but I'd estimate that we're just scratching the surface re: ways to harm somebody by making their tech behave in surprising ways. 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."
  - vlovich123 2y ago
    Ok, give me access to a subdomain I control and I’m phoning home and there’s no way you can restrict mysubdomain.foo.com/phonehome vs mysubdomain.foo.com/normal - and even if you tried to do path restrictions, I can arbitrarily side-channel phoning home with normal access (which by the way you can’t unless you’re sniffing the encrypted HTTP session somehow). 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.
- surajrmal 2y ago
  Most components don't need to talk to the network though and therefore do not. The ones that do can do powerful things but creating narrower capabilities to restrict what they can do is very much feasible.
  - vlovich123 2y ago
    I’m not against capabilities. I’m just highlighting it’s for the developers to implement protections against malicious intrusions against the OS, not for users to protect against developers doing malicious things.
    - surajrmal 2y ago
      While there is no direct UX exposing this to an end user, it hypothetically be used as the basis of such UI. The parent of a component gets to ultimately decide what capabilities it routes to a child component. It's not like landlock where the process decides to sandbox itself after it's already running. Similar to a user constructing a VM to run a hypothetically malicious program, the same could be done much more lightweight with a fuchsia component.
      - vlovich123 2y ago
        All I said is that in the general case you’re not going to be able to rely on capabilities to do things like prevent phoning home or otherwise doing things you semantically define as harmful. This isn’t a UX issue - this is a technical issue. Capabilities, outside from very rare circumstances, can’t enforce it no matter how you structure this. The only rare circumstances is if you can restrict access to servers that aren’t owned by the same people as wrote the component. As soon as you give access that allows access, they can implement it in ways that capabilities can’t prevent.
        stouset 2y ago
        Your perspective is coming from a very rigid all-or-nothing mentality and I don’t think it’s wise to see things that way. 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.
nicce 2y ago
Sounds like it has just AppArmor/Seccomp/SELinux policies built in. You usually reach the same with previous.
- surajrmal 2y ago
  The difference is that those solutions are mandatory access control. Fuchsia doesn't have a global namespace that everyone shares. Each component gets it's own view of the world based on what is passed to it. This is often easier to work with then MAC. It's similar to writing a program without relying on globals for state, but instead passing everything into every function that it needs.
  - nicce 2y ago
    > Each component gets it's own view of the world based on what is passed to it. But isn’t that exactly the same as MAC with default deny..? Different terms.
    - surajrmal 2y ago
      Yes it's different because mac implies global understanding. Capability routing decisions are local.
ferfumarma 2y ago
It's a lot like sandstorm; the web hosting platform that Kenon Varda created. It failed as a corporation, but is still open source. It's a shame: it was before it's time and still holds up incredibly well.

vlovich123 2y ago

Sure, but it is allowed, at least as far as I understand, to phone home if it otherwise needs network access. In practice it’s really hard to prevent unauthorized semantic network access once you allow any network access. 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.

bestorworse 2y ago
The joy of having a properly implemented capability system is that, well, you can create arbitrary capabilities. 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.
- dekhn 2y ago
  In my experience lots of folks simply won't work with capability systems no matter how good the implementation is or whatever level of security and configuration granularity is provided. For many people it's just extra friction in search of a use case.
  - surajrmal 2y ago
    It makes testing a lot easier honestly. Also keep in mind that mobile apps and web apps are fairly capability oriented these days, so I wouldn't say no one will work with it...
  - onjectic 2y ago
    I am curious what your experience is with capability based security? They are still incredibly niche(unfortunately) so I’ve never had a chance to work with one at a job.
  - __MatrixMan__ 2y ago
    I'm just hearing about capability systems today, so your experience is undoubtedly richer than mine, but I'd estimate that we're just scratching the surface re: ways to harm somebody by making their tech behave in surprising ways. 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."
- vlovich123 2y ago
  Ok, give me access to a subdomain I control and I’m phoning home and there’s no way you can restrict mysubdomain.foo.com/phonehome vs mysubdomain.foo.com/normal - and even if you tried to do path restrictions, I can arbitrarily side-channel phoning home with normal access (which by the way you can’t unless you’re sniffing the encrypted HTTP session somehow). 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.
surajrmal 2y ago
Most components don't need to talk to the network though and therefore do not. The ones that do can do powerful things but creating narrower capabilities to restrict what they can do is very much feasible.
- vlovich123 2y ago
  I’m not against capabilities. I’m just highlighting it’s for the developers to implement protections against malicious intrusions against the OS, not for users to protect against developers doing malicious things.
  - surajrmal 2y ago
    While there is no direct UX exposing this to an end user, it hypothetically be used as the basis of such UI. The parent of a component gets to ultimately decide what capabilities it routes to a child component. It's not like landlock where the process decides to sandbox itself after it's already running. Similar to a user constructing a VM to run a hypothetically malicious program, the same could be done much more lightweight with a fuchsia component.
    - vlovich123 2y ago
      All I said is that in the general case you’re not going to be able to rely on capabilities to do things like prevent phoning home or otherwise doing things you semantically define as harmful. This isn’t a UX issue - this is a technical issue. Capabilities, outside from very rare circumstances, can’t enforce it no matter how you structure this. The only rare circumstances is if you can restrict access to servers that aren’t owned by the same people as wrote the component. As soon as you give access that allows access, they can implement it in ways that capabilities can’t prevent.
      - stouset 2y ago
        Your perspective is coming from a very rigid all-or-nothing mentality and I don’t think it’s wise to see things that way. 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.

nicce 2y ago

Sounds like it has just AppArmor/Seccomp/SELinux policies built in. You usually reach the same with previous.

surajrmal 2y ago
The difference is that those solutions are mandatory access control. Fuchsia doesn't have a global namespace that everyone shares. Each component gets it's own view of the world based on what is passed to it. This is often easier to work with then MAC. It's similar to writing a program without relying on globals for state, but instead passing everything into every function that it needs.
- nicce 2y ago
  > Each component gets it's own view of the world based on what is passed to it. But isn’t that exactly the same as MAC with default deny..? Different terms.
  - surajrmal 2y ago
    Yes it's different because mac implies global understanding. Capability routing decisions are local.

ferfumarma 2y ago

It's a lot like sandstorm; the web hosting platform that Kenon Varda created. It failed as a corporation, but is still open source. It's a shame: it was before it's time and still holds up incredibly well.