3 ms·

What you need is not a capability safe language, but rather a tool to make application jails and similar systems more accessible. Your os exists for a reason,

What you need is not a capability safe language, but rather a tool to make application jails and similar systems more accessible. Your os exists for a reason, let it handle the sandboxing for you, and not the language. Otherwise you fall into troubles later with different sandboxing vulnerabilities in different compilers. Have a codebase that compiles using deprecated features which are removed on language version 2.1 ? “Tough luck, security patches only exists in 3.1 and above, guess you’ll have to stay unsafe” Not to mention the pain it would bring on languages to backport safety features to older LTS releases of the compiler. Just why?, let the os handle these things for you. It is called an operating system for a reason. Log4j vulnerability was minimised in any organisation that restricts its applications network capability to whitelisted machines only, with the help of its OS features. (Yes your application might need network access, so run it through a reverse proxy and filter the traffic based on strict set of rules)

dccoolgai 5y ago
Capabilities model is not about "features" which might be deprecated, but more about "access to standard resources". Capabilities e.g. doesn't care that you are running version 3.1.73 of a certain dependency, it cares that you want to open a network connection to 123.76.34 or that you want /usr/bin/secret file.txt.
- samus 5y ago
  The version [of a dependency] starts to matter if it blocks upgrade to a version of the platform that would allow to control a specific new capability.
justinpombrio 5y ago
This is a good point. I talked about capabilities at the language level, but they're just as important if not more-so at the operating system level. If you have capabilities in the programming language, then you can make guarantees about what resources (like the network) your program's transitive dependencies can use (in process). If you have capabilities in the OS, then you can make guarantees about what resources a process can use. EDIT: this is how you would use capabilities in the OS to obtain "application jails". But capabilities would be more flexible here, for example by allowing processes to share them. As monocasa points out in a separate thread, log4j is actually a messy example---messier than I realized when I wrote this post---because the way it (is? might be?) set up is that your application runs in one process, and JNDI in another. Which brings up a lot of design questions around capabilities in the OS and in the language and in how they interact that I don't know much about. But the primary point of capabilities is to limit how access control can flow from place to place, using standard data-flow mechanisms. In a programming language, this means tying access to whether you have a pointer to an object. In an OS, I think this looks more like OS-level permissions granted to a process, that processes can share with each other. You don't have some big table somewhere saying who is allowed to do what. Instead, access is granted by a thing, that you can pass around. When you get used to the idea, it just feels very natural and powerful.
naasking 5y ago
Sandboxing cannot provide the same security benefits of capabilities, even in principle.

dccoolgai 5y ago

Capabilities model is not about "features" which might be deprecated, but more about "access to standard resources". Capabilities e.g. doesn't care that you are running version 3.1.73 of a certain dependency, it cares that you want to open a network connection to 123.76.34 or that you want /usr/bin/secret file.txt.

samus 5y ago
The version [of a dependency] starts to matter if it blocks upgrade to a version of the platform that would allow to control a specific new capability.

justinpombrio 5y ago

This is a good point. I talked about capabilities at the language level, but they're just as important if not more-so at the operating system level. If you have capabilities in the programming language, then you can make guarantees about what resources (like the network) your program's transitive dependencies can use (in process). If you have capabilities in the OS, then you can make guarantees about what resources a process can use. EDIT: this is how you would use capabilities in the OS to obtain "application jails". But capabilities would be more flexible here, for example by allowing processes to share them. As monocasa points out in a separate thread, log4j is actually a messy example---messier than I realized when I wrote this post---because the way it (is? might be?) set up is that your application runs in one process, and JNDI in another. Which brings up a lot of design questions around capabilities in the OS and in the language and in how they interact that I don't know much about. But the primary point of capabilities is to limit how access control can flow from place to place, using standard data-flow mechanisms. In a programming language, this means tying access to whether you have a pointer to an object. In an OS, I think this looks more like OS-level permissions granted to a process, that processes can share with each other. You don't have some big table somewhere saying who is allowed to do what. Instead, access is granted by a thing, that you can pass around. When you get used to the idea, it just feels very natural and powerful.

naasking 5y ago

Sandboxing cannot provide the same security benefits of capabilities, even in principle.