[HN Gopher] Why not object capability languages?
       ___________________________________________________________________
        
       Why not object capability languages?
        
       Author : mike_hearn
       Score  : 43 points
       Date   : 2025-05-11 18:57 UTC (4 hours ago)
        
 (HTM) web link (blog.plan99.net)
 (TXT) w3m dump (blog.plan99.net)
        
       | vvanders wrote:
       | One capability mechanism that's in wide use but not really well
       | known or touched on in the article is Androids RPC mechanism,
       | Binder(and a lot of the history predates Android from what I
       | recall).
       | 
       | Binder handles work just like object capabilities, you can only
       | use what's sent to you and process can delegate out other binder
       | handles.
       | 
       | Android hides most of this behind their permission model but the
       | capability still exist and can be implemented by anyone in the
       | system.
        
       | jFriedensreich wrote:
       | The capability system i hear talked about too little for some
       | reason and is even more "chromey baby" is workerd using isolates.
       | You can clearly see the lineage from sandstorm/ capnp and its
       | kind of crazy something like this is finally in a mainstream
       | platform. Sure, the concept is not taken to the extreme without
       | much possibility to delegate / demote capabilities at runtime,
       | but the direction is clearly what we need. Whenever i have to
       | come back to other environments I immediately feel the lack of
       | trust, clarity and control these have.
        
         | refulgentis wrote:
         | For some reason I'm having a _horrible_ time googling workerd,
         | any tips? -- also, I might be looking up the wrong thing? (I 'm
         | hoping to learn more about the environment you are in before
         | you "have to come back to other environments")
        
           | ameliaquining wrote:
           | https://github.com/cloudflare/workerd
        
       | duncanbeevers wrote:
       | There's a great paper implementing this idea in the node.js
       | ecosystem; [BreakApp: Automated, Flexible Application Compartment
       | alization](https://ic.ese.upenn.edu/pdf/breakapp_ndss2018.pdf)
       | which modifies the `require` signature to allow specifying a
       | security scope in which the module can be run.
       | 
       | It doesn't quite work at the capabilities level, but it does
       | provide some novel protections against unusual supply-chain
       | attacks such as denial-of-service attacks which may otherwise
       | require no special capabilities.
        
       | jdougan wrote:
       | I think Newspeak may have potential in this area.
        
       | coolcase wrote:
       | Ecosystems get it right because they have to. E.g. iOS and
       | Android etc. This ain't so good on desktop systems.
       | 
       | Probably the compiled program should just get tbe permissions it
       | needs.
       | 
       | A simple capability system for libraries might be the good that
       | is the enemy of perfect:
       | 
       | Pure - can only access compute and its own memory plus passed in
       | parameters (needs immutable languages or serialization at
       | interop)
       | 
       | Storage IO - Pure but can do Storage IO. IO on what? Anything the
       | program has access to.
       | 
       | Network IO - similar concept
       | 
       | Desktop in Window - can do UI stuff in the window
       | 
       | Desktop General - models, notifications, new windows etc.
       | 
       | Etc...
       | 
       | Not very fine grained but many libraries cab be Pure.
       | 
       | It ain't perfect.
       | 
       | A Pure library that formats a string can still inject some nasty
       | JS hoping that you'll use that string on a web page!
       | Ultimately... useful computation is messy and you can't secure
       | everything in advance through capabilities alone.
        
         | ameliaquining wrote:
         | IIUC iOS and Android don't have library sandboxing; any code
         | that you allow to run in your app's process can access the
         | whole address space. Apps themselves are sandboxed, but that
         | doesn't help with the class of problem that this post is about.
        
       | jauntywundrkind wrote:
       | The WASI systems libraries that define the standard platform for
       | WebAssembly/wasm are Capability-based.
       | 
       | From their first high level goal:
       | 
       | > _Define a set of portable, modular, runtime-independent, and
       | WebAssembly-native APIs which can be used by WebAssembly code to
       | interact with the outside world. These APIs preserve the
       | essential sandboxed nature of WebAssembly through a_ Capability-
       | based API _design._
       | 
       | https://github.com/WebAssembly/WASI/blob/main/README.md#wasi...
        
       | jerf wrote:
       | Yup, this is all really hard, which is why it hasn't been much
       | more than a research project up to this point.
       | 
       | If I had to guess, the supply chain problems that may eventually
       | cause this to be created will need to get, oh, I don't know, call
       | it two orders of magnitude worse before the system as a whole
       | really takes note. Then, since you can't really write a new
       | language just for this, even though I'd like that to happen,
       | it'll get bodged on to the side of existing languages and it
       | won't be all that slick.
       | 
       | That said, I do think there's probably some 80/20 value in
       | creating an annotation to the effect of "this library doesn't
       | need filesystem access or sockets" and having perhaps a linter or
       | some other external tool validate it externally to the main
       | language compiler/runtime. The point of this would not be to
       | solve the capabilities problem for libraries that are doing
       | intrinsically tricky things, because that's really hard to do
       | correctly, but just to get a lot of libraries out of the line of
       | fire. There's a lot of libraries that already don't need to do
       | those things, and more that could easily be tweaked to just take
       | passed-in file handles or whatever if there was a concrete reason
       | to design them that way.
       | 
       | The library that I personally could do the most damage with on my
       | GitHub is a supervision tree library for Go. It doesn't need any
       | capabilities to speak of. The closest thing is that you can pass
       | in a logger object and that is constrained to specific calls too.
       | Even a hack that just lets me say that this library doesn't need
       | anything interesting would at least get that out of the set of
       | libraries that could be exploited.
       | 
       | Or to put it another way, rather than trying to perfectly label
       | all the code doing tricksy stuff, maybe we can start by labelling
       | the code that _doesn 't_.
       | 
       | I'd also point out that I think the question of _libraries_ is
       | different than things like Chrome isolation. Those things are
       | good, but they 're for treating data carefully and limiting blast
       | radiuses; I'm looking at the problem of "if I download this
       | library and miss one single file is it going to upload every AWS
       | token it can find to someone who shouldn't have them".
        
         | pyinstallwoes wrote:
         | Shouldn't it be automatic based on behavior? An annotation is
         | ripe for exploitation if the system itself can't make sense of
         | its own parts.
        
           | jerf wrote:
           | That would be preferable, certainly. I'm staying vague
           | because there's a world of differences in how all the
           | languages would most easily be able to implement something
           | like this and I'm trying to stay language non-specific.
           | Imagine how you'd solve this in Rust versus Ruby.
        
       | burnt-resistor wrote:
       | See also: formal verification methodologies like those applied to
       | seL4. Holistic practices of upping rigorous proofs of safety and
       | correctness is the elephant in the room besides merely testing,
       | language features, or any one solution.
        
       ___________________________________________________________________
       (page generated 2025-05-11 23:00 UTC)