In light of some feedback we've received on the article, some
clarification is needed. The ocap (object-capabilities) approach does
not by itself make systems secure. Rather, it an enormous step
towards making systems secureable. Even after taking this step, making
complex systems secure can still be very hard, depending on the
specifics.<p>In an ocap system such as SES <a href="https://github.com/Agoric/SES" rel="nofollow">https://github.com/Agoric/SES</a> , an
object can only directly cause effects on the world outside itself by
using the capabilities it holds. Objects come in graphs held together
by references, so an object can still only cause effects, directly or
indirectly, according to its connectivity to the rest of the system
via references. The different between direct effects vs general
causation is the difference between permission and authority
[1,2]. Permission is often vastly easier to reason about than
authority, but our safety depends on reasoning about limits on
authority.<p>The event-stream exploit would have been prevented merely by practicing
the principle of least permission. Hence this article did not need to
go into these subtleties. Hence, this exploit is a good example for
introducing people to these concepts, tempting them to dig deeper [3].<p>[1] Paradigm Regained <a href="http://www.erights.org/talks/asian03/paradigm-revised.pdf" rel="nofollow">http://www.erights.org/talks/asian03/paradigm-revised.pdf</a><p>[2] Permission and Authority Revisited <a href="https://ai.google/research/pubs/pub45570" rel="nofollow">https://ai.google/research/pubs/pub45570</a><p>[3] References page <a href="https://agoric.com/references/" rel="nofollow">https://agoric.com/references/</a>
This npm / event-stream incident is the perfect teaching moment for POLA (Principle of Least Authority), and for the need to support least authority for JavaScript libraries.<p><a href="https://www.youtube.com/watch?v=9Snbss_tawI&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2" rel="nofollow">https://www.youtube.com/watch?v=9Snbss_tawI&list=PLKr-mvz8uv...</a> is my presentation to the Node security team, explaining many of these issues prior to this particular incident.
What would be the sane behaviour for the following situation?<p>my app imports an http request library and gives it net permissions<p>my app imports a templating library and gives it no permissions<p>the templating library is malicious and tries to import well known http request libraries, and finds the one i imported, which has been given net permissions.<p>or what if you give the templating library a mixin of some sort which accidentally exposes the privileged http library
"This isn’t the case in a language like Java, where access to the outside world is mixed in with other functionality."<p>That's why there is a SecurityManager: <a href="https://docs.oracle.com/javase/tutorial/essential/environment/security.html" rel="nofollow">https://docs.oracle.com/javase/tutorial/essential/environmen...</a> that - if anything - is extremely granular.
At <a href="https://twitter.com/spudowiar/status/1069680974110306306" rel="nofollow">https://twitter.com/spudowiar/status/1069680974110306306</a> Saleem Rashid raises an example of this principle that is especially easy to overlook, where authority arises from one entity relying on the unchecked veracity of another.