Surprised that Genode isn't mentioned in this context:<p><a href="https://genode.org" rel="nofollow">https://genode.org</a><p>Ok it's not a language-based approach. But interesting project aiming for similar goals as discussed in the article. And a nice counter-example to:<p><i>"Not one OS has a sandboxing API that is all of documented, stable and usefully powerful"</i>
The WASI systems libraries that define the standard platform for WebAssembly/wasm are Capability-based.<p>From their first high level goal:<p>> <i>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</i> Capability-based API <i>design.</i><p><a href="https://github.com/WebAssembly/WASI/blob/main/README.md#wasi-high-level-goals">https://github.com/WebAssembly/WASI/blob/main/README.md#wasi...</a>
Caja's spiritual successor is HardenedJS (<a href="https://hardenedjs.org/" rel="nofollow">https://hardenedjs.org/</a>), authored by some of the same folks (Mark Miller + friends). As I understand it, Caja attempted to secure not just javascript but the DOM as well, which ultimately proved to be a too large, interconnected, and rapidly changing surface to keep up with.<p>LavaMoat (<a href="https://lavamoat.github.io/" rel="nofollow">https://lavamoat.github.io/</a>), while not quite object capabilities, builds on HardenedJS to provide runtime supplychain security protections to js apps (nodejs or browser) by eliminating ambient authority and only exposing global capabilities per npm package according user-specified policy. LavaMoat is used in production at MetaMask, protecting ~300M users.<p>OCapN (<a href="https://github.com/ocapn/ocapn/">https://github.com/ocapn/ocapn/</a>) is a nascent effort to standardize a distributed object capability protocol (transferring capabilities across mutually distrusting peers).
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).<p>Binder handles work just like object capabilities, you can only use what's sent to you and process can delegate out other binder handles.<p>Android hides most of this behind their permission model but the capability still exist and can be implemented by anyone in the system.
Why not?<p>Answering the question: “Can this process access this resource?” is equivalent to solving the halting problem.<p>There’s a reason simpler access control models are popular. Even ACLs are completely untenable in practice. Look at all the trouble accidentally-public s3 buckets create.
Yup, this is all really hard, which is why it hasn't been much more than a research project up to this point.<p>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.<p>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.<p>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.<p>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 <i>doesn't</i>.<p>I'd also point out that I think the question of <i>libraries</i> 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".
There's a great paper implementing this idea in the node.js ecosystem; [BreakApp: Automated, Flexible Application Compartmentalization](<a href="https://ic.ese.upenn.edu/pdf/breakapp_ndss2018.pdf" rel="nofollow">https://ic.ese.upenn.edu/pdf/breakapp_ndss2018.pdf</a>) which modifies the `require` signature to allow specifying a security scope in which the module can be run.<p>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.
It's unclear to me why the "god object" pattern described in the article isn't a good solution. The pattern in the article is different from the "god object" pattern as commonly known[1], in that the god object in the article doesn't need to be referenced after initialization. It's basically used once during initialization then forgotten.<p>It's normal for an application to be built from many independent modules that accept their dependencies as inputs via dependency inversion[2]. The modules are initialized at program start by code that composes everything together. Using the "god object" pattern from the article is basically the same thing.<p>[1] <a href="https://en.wikipedia.org/wiki/God_object" rel="nofollow">https://en.wikipedia.org/wiki/God_object</a>
[2] <a href="https://en.wikipedia.org/wiki/Dependency_inversion_principle" rel="nofollow">https://en.wikipedia.org/wiki/Dependency_inversion_principle</a>
Ecosystems get it right because they have to. E.g. iOS and Android etc. This ain't so good on desktop systems.<p>Probably the compiled program should just get tbe permissions it needs.<p>A simple capability system for libraries might be the good that is the enemy of perfect:<p>Pure - can only access compute and its own memory plus passed in parameters (needs immutable languages or serialization at interop)<p>Storage IO - Pure but can do Storage IO. IO on what? Anything the program has access to.<p>Network IO - similar concept<p>Desktop in Window - can do UI stuff in the window<p>Desktop General - models, notifications, new windows etc.<p>Etc...<p>Not very fine grained but many libraries cab be Pure.<p>It ain't perfect.<p>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.
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.
An interesting analogy could be Rust's unsafe. One important property of unsafe is that it's not inherently contagious. A safe function can contain an unsafe block, and that unsafe block can contain unsafe code. What this entails in practice is the function's author pinky-swearing that, despite its internals, the author promises that the function won't violate memory safety. The analogy isn't exact. In particular, functions are allowed to place human language constraints on their callers, which aren't verified, in order to uphold that guarantee. I wonder why there hasn't been any work done in this direction. It seems promising, and if there's any obvious walls that this hits, at least I hadn't figured out any.
Ahh, JAAS... Java applets were removed, but JAAS, which only existed to support applets, could not be removed because there was lots of code that depended on the Login and Subject classes and the runAs() method. Why would such code exist though, if JAAS existed only to support applets? Well, because the Login class could be used to acquire credentials. For example the Krb5Login class could be used as a Java kinit in Kerberos environments.<p>Anyways, JAAS' Permission class and model are weak, but yeah, they could be used to limit libraries' capabilities. A capability model would be much better than a permission model.
Without speaking to all of the issues, this is all made much harder by the underlying hardware having extremely bad defaults. The idea that running code on the hardware is itself an unsafe operation means that any time you want to touch it you need proxies and intermediate languages and all this by default.<p>It's pretty easy for me to imagine a world where running code was safe by default, and this followed all the way to the top. It's obviously not that onerous, else JavaScript wouldn't be as successful as it is. Most of the details the post touches on are then just package management and grouping concerns.
<a href="https://files.spritely.institute/papers/spritely-core.html" rel="nofollow">https://files.spritely.institute/papers/spritely-core.html</a><p>Spritely seems very relevant, but I don't see it get much mentions when this pops up
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.