4 ms·
The lack of secure composability in almost all existing languages. You cannot import untrusted code and run it in a sandbox. Unless you are completely functiona
by 7373737373 8y ago
The lack of secure composability in almost all existing languages. You cannot import untrusted code and run it in a sandbox. Unless you are completely functional, you cannot restrict the effects of your own code either.
The solution to this seems to be the object capability (key) security paradigm, where you combine authority and designation (say, the right to open a specific file, a path combined with an access right). There are only immutable globals. Sandboxing thus becomes only a matter of supplying the absolutely needed keys. This also enables the receiver to keep permissions apart like variables, thus preventing the https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Confused_deputy_problem (no ambient authority).
Even with languages that have security policies (Java, Tcl, ?), control is not fine grained, and other modes of interference are still possible: resource exhaustion for example. Most VMs/languages do not keep track of execution time, number of instructions or memory use. Those that do enable fascinating use cases: https://stackless.readthedocs.io/en/latest/library/stackless/pickling.html https://stackless.readthedocs.io/en/latest/library/stackless...
All of this seems to become extremely relevant, because sufficient security is a fundamental requirement for cooperation in a distributed world.
- mjw1007 8y agoSpectre is another mode of interference, and perhaps one which means we're going to have to give up altogether on running untrusted code without at least a process boundary.
- justincormack 8y agoThe JavaScript Realms API adds secure object capabilities https://github.com/tc39/proposal-realms/blob/master/README.md https://github.com/tc39/proposal-realms/blob/master/README.m...
- bryal 8y agoI recently had a lecture about something related to this in a course on advanced functional programming. Basically we were shown how you can implement a monad in Haskell that lets you preserve sensitive data when executed by untrusted code. Together with the SafeHaskell language extension, which disallows libraries to use operations that could potentially break the invariants, this seems like a very cool concept! Functional pearl: http://www.cse.chalmers.se/~russo/publications_files/pearl-russo.pdf http://www.cse.chalmers.se/~russo/publications_files/pearl-r... Slides: https://1drv.ms/p/s!Ahd2uwlk3jmIlCZr0spYc_I-OveR https://1drv.ms/p/s!Ahd2uwlk3jmIlCZr0spYc_I-OveR Source: https://bitbucket.org/russo/mac-lib https://bitbucket.org/russo/mac-lib
- chalst 8y agoWell put. I'd add that this is a case where the decoupling of OS and language design is bad: capabilities are much more valuable if the OS can provide a sufficiently expressive basis for them. I'm watching Zircon with great interest. https://github.com/fuchsia-mirror/zircon https://github.com/fuchsia-mirror/zircon
- blacksqr 8y agoTcl has the concept of "safe interpreters" which can be spawned as slaves of the main interpreter. There is a default safe interpreter policy, which is fully scriptable for customization. Among the available customizations in a safe interpreter are: restriction of use of individual commands, ability to set a time limit for execution of code, a limit to number of commands executed, and depth of recursion. Memory usage can't be directly limited, but Tcl has trace features that allow examination of a variable value when set, so one could write custom code that prevents total contents of variables from exceeding a specified limit.