5 ms·

Just to say, but You are describing an effect type system. (Or, to the "types are static" people, possibly a dynamic effect system.) Capabilities taken literal

Just to say, but You are describing an effect type system. (Or, to the "types are static" people, possibly a dynamic effect system.) Capabilities taken literally are more of a network thing (it's how you prove you have access to a computer that doesn't trust you). On a language, you don't need the capabilities themselves.

wyago 2y ago
Effect typing can achieve capability security statically, but I've also frequently seen capabilities used to describe dynamic capability systems via various methods involving passing capabilities down as reified objects of some sort. This of course also depends on some related static guarantees that a function can't access ambient capabilities not passed directly in their arguments, but this is a much simpler static guarantee than effect typing and doesn't require specific analysis over normal parameter types.
jonahx 2y ago
> Capabilities taken literally are more of a network thing (it's how you prove you have access to a computer that doesn't trust you). On a language, you don't need the capabilities themselves. You may be thinking of the term in a different context. In this context, they are a general security concept and definitely apply to more than the network, including languages: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ (this is a great article) https://www.ponylang.io/ https://www.ponylang.io/ etc...
- bluGill 2y ago
  > On a language, you don't need the capabilities themselves. Why not? Sometimes I want that. Just today I was looking at some code and realized that it was being used by groups that shouldn't. The code needs to be there and is great for the correct users, but someone is going around our architecture and we didn't notice it.
  - jonahx 2y ago
    You are replying to the wrong post. I was quoting the GP.
ajb 2y ago
Capabilities are more general than that. They have been around for a long time; one academic design implemented them in hardware in 1970[1]. they can be used in as fine grained a way as 'you are allowed to access this array in memory and nothing else'- which is the sort of thing that needs to be built into languages to be maximally useful. [1] https://en.wikipedia.org/wiki/CAP_computer https://en.wikipedia.org/wiki/CAP_computer
- convolvatron 2y ago
  I disagree about your last point. I looked at a product design once which allowed one to associate a profile with each third party library. accesses across library boundaries were implementing using classic call gates from segmented architectures which could change memory visibility and syscall filtering. so while I agree that language integration is really useful, I think you can get a lot out of appropriate support in the runtime, most notably the library loader.
  - ajb 2y ago
    Yes, that's why I said "to be maximally useful" instead of "to be useful"
justinpombrio 2y ago
You can do a lot with capabilities at the language level, if the language supports it. It doesn't require effect types: it's extremely boring from a type system perspective, which is an advantage. Imagine these changes to a language, making it "capability safe": - There is a `Network` object, and it's the only way to access the network. Likewise, there's a `Filesystem` object, and it's the only way to access the file system. - Code cannot construct a `Network` or `Filesystem` object. Like, you just can't, there's no constructor. - The `main()` function is passed a `Network` object and a `Filesystem` object. Consider the consequences of this. The log4j vulnerability involved a logging library doing network access. In a capability safe language, this could only happen if you passed a `Network` object to the logger, either in its constructor or in one of its methods. So the vulnerability is still possible. But! Now you can't be surprised that your logger was accessing the network because you gave it the network. And a logger asking for network access is sufficiently sketchy that log4j almost certainly would have made network access optional for the few users that wanted that feature, which would have prevented the vulnerability for everyone else! I talked about there being a single monolithic `Filesystem` object. That is what would be passed into `main()`, but you should also be able to make finer grained capabilities out of it. For example, you should be able to use the `Filesystem` object to construct an object that has read/write access to a directory and its subdirectories. So if a function takes one of these as an argument, you know its not mucking around outside of the directory you gave it. Capability safety within a language is stronger than the sort of capability safety you can get at the process level or at the level of multiple machines. But we want those too!
- gnafkcud 2y ago
  this was the original approach for Java, and the main idea behind being able to ship untrusted apps directly to the user and run them in the browser tomcat also gave different privilege levels to different parts of the classpath nice idea, but didn't seem to work in practice
  - justinpombrio 2y ago
    That's what I'm calling capabilities at the application level (where you say "this .jar can't access the network"), rather than at the language level (where you say "this function wasn't given access to the network as an argument"). I don't think any widely known language has tried capabilities at the language level. (The language not widely known that does it is E.) The real power will come when you can mix them. In one direction, that looks like `main()` not getting passed a `Network` object because the ".jar" wasn't granted network access. In the other direction, that looks like the system C library you invoked failing to access the network because when you invoked it from Java you failed to provide a `Network` object, so it was automatically sandboxed to not be able to access the network.

wyago 2y ago

Effect typing can achieve capability security statically, but I've also frequently seen capabilities used to describe dynamic capability systems via various methods involving passing capabilities down as reified objects of some sort. This of course also depends on some related static guarantees that a function can't access ambient capabilities not passed directly in their arguments, but this is a much simpler static guarantee than effect typing and doesn't require specific analysis over normal parameter types.

jonahx 2y ago

> Capabilities taken literally are more of a network thing (it's how you prove you have access to a computer that doesn't trust you). On a language, you don't need the capabilities themselves. You may be thinking of the term in a different context. In this context, they are a general security concept and definitely apply to more than the network, including languages: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ (this is a great article) https://www.ponylang.io/ https://www.ponylang.io/ etc...

bluGill 2y ago
> On a language, you don't need the capabilities themselves. Why not? Sometimes I want that. Just today I was looking at some code and realized that it was being used by groups that shouldn't. The code needs to be there and is great for the correct users, but someone is going around our architecture and we didn't notice it.
- jonahx 2y ago
  You are replying to the wrong post. I was quoting the GP.

ajb 2y ago

Capabilities are more general than that. They have been around for a long time; one academic design implemented them in hardware in 1970[1]. they can be used in as fine grained a way as 'you are allowed to access this array in memory and nothing else'- which is the sort of thing that needs to be built into languages to be maximally useful. [1] https://en.wikipedia.org/wiki/CAP_computer https://en.wikipedia.org/wiki/CAP_computer

convolvatron 2y ago
I disagree about your last point. I looked at a product design once which allowed one to associate a profile with each third party library. accesses across library boundaries were implementing using classic call gates from segmented architectures which could change memory visibility and syscall filtering. so while I agree that language integration is really useful, I think you can get a lot out of appropriate support in the runtime, most notably the library loader.
- ajb 2y ago
  Yes, that's why I said "to be maximally useful" instead of "to be useful"

justinpombrio 2y ago

You can do a lot with capabilities at the language level, if the language supports it. It doesn't require effect types: it's extremely boring from a type system perspective, which is an advantage. Imagine these changes to a language, making it "capability safe": - There is a `Network` object, and it's the only way to access the network. Likewise, there's a `Filesystem` object, and it's the only way to access the file system. - Code cannot construct a `Network` or `Filesystem` object. Like, you just can't, there's no constructor. - The `main()` function is passed a `Network` object and a `Filesystem` object. Consider the consequences of this. The log4j vulnerability involved a logging library doing network access. In a capability safe language, this could only happen if you passed a `Network` object to the logger, either in its constructor or in one of its methods. So the vulnerability is still possible. But! Now you can't be surprised that your logger was accessing the network because you gave it the network. And a logger asking for network access is sufficiently sketchy that log4j almost certainly would have made network access optional for the few users that wanted that feature, which would have prevented the vulnerability for everyone else! I talked about there being a single monolithic `Filesystem` object. That is what would be passed into `main()`, but you should also be able to make finer grained capabilities out of it. For example, you should be able to use the `Filesystem` object to construct an object that has read/write access to a directory and its subdirectories. So if a function takes one of these as an argument, you know its not mucking around outside of the directory you gave it. Capability safety within a language is stronger than the sort of capability safety you can get at the process level or at the level of multiple machines. But we want those too!

gnafkcud 2y ago
this was the original approach for Java, and the main idea behind being able to ship untrusted apps directly to the user and run them in the browser tomcat also gave different privilege levels to different parts of the classpath nice idea, but didn't seem to work in practice
- justinpombrio 2y ago
  That's what I'm calling capabilities at the application level (where you say "this .jar can't access the network"), rather than at the language level (where you say "this function wasn't given access to the network as an argument"). I don't think any widely known language has tried capabilities at the language level. (The language not widely known that does it is E.) The real power will come when you can mix them. In one direction, that looks like `main()` not getting passed a `Network` object because the ".jar" wasn't granted network access. In the other direction, that looks like the system C library you invoked failing to access the network because when you invoked it from Java you failed to provide a `Network` object, so it was automatically sandboxed to not be able to access the network.