4 ms·

I was agreeing until I got to this nonsense: An object in a type-safe language can contain capabilities for resources which it uses to implement its meth

I was agreeing until I got to this nonsense: An object in a type-safe language can contain capabilities for resources which it uses to implement its methods, without those capabilities being available to the code calling those methods. Java-style stack inspection can restrict user or library code to deny access at runtime to unauthorized methods. Capability-safe architectures such as CHERI prevent code from accessing memory that it doesn't have an explicit capability for. Software fault isolation can allow Multics-style "call gates", where a library has a different privilege level from other code. Aside from CHERI, which requires specialized hardware, none of these actually work and none of the implementations you will find in the wild are anything but snakeoil. Just use a service, it's the only local security boundary current OSes even pretend to enforce.

eru 6y ago
However, if your user agrees to be limited (because it prevents them from making mistakes), we have fairly reliable methods. But yes, they require the user of your library to cooperate.
catern 6y ago
>none of these actually work and none of the implementations you will find in the wild are anything but snakeoil This is wrong. The foundation of the modern web is safe Javascript implementations. BPF/eBPF is another widespread technology using isolation mechanisms like this. All of these techniques work. As I mentioned in the very next sentence, only the first in that list is common, but that doesn't mean the rest don't work. If you have found some fundamental hole in NaCL or CHERI or JVM security which makes them ineffective, feel free to publish your results.
- bpodgursky 6y ago
  I think you are talking about different things. I have absolutely decompiled obfuscated third-party Java libraries, fiddled with a few variables or method signatures, and recompiled + used them. JVM security has nothing to do with this.
  - catern 6y ago
    You're correct that obfuscation of Java libraries has nothing to do with Java stack inspection/JVM security... but the latter is what the article talks about and what is cited above, so not sure why you have just now brought up decompiling obfuscated Java libraries, which is, as you say, totally unrelated...
    - bpodgursky 6y ago
      What it says is "Java-style stack inspection can restrict user or library code to deny access at runtime to unauthorized methods.", which doesn't seem true to me, if the user has access to the library binaries. It's very possible for the user to just patch the library and use it however they want. It's possible (although I'm not especially convinced) that you can prevent the user from reflectively doing this at runtime, but that's not the only way to access unauthorized methods.
      - rowland66 6y ago
        Yes, the OP has this backwards. The Java sandbox would allow an application to limit the access granted to a library to protect from a malicious library. It does not protect a library from being used by an application in way that was not intended by the library creator. It is certainly not a means of enforcing a licensing scheme.
        catern 6y ago
        >It is certainly not a means of enforcing a licensing scheme. Could you explain what gave you the impression that this was about licensing schemes? That was definitely not my intention.
- bcoates 6y ago
  Huh? NaCL is dead, and as far as I know nothing relies on the JVM sandbox for security anymore (and it was a disaster when they tried). These also rely on wrapping the entire userspace into a sandbox, which is hardly relevant to the libraries vs. services thing. You can't inspect a stack from inside the attacker's process and expect that to do anything at all, let alone control access to a resource.
  - catern 6y ago
    >You can't inspect a stack from inside the attacker's process and expect that to do anything at all, let alone control access to a resource. See the article: >If user code is running on a sufficiently advanced platform, one not administered by the user, then a library can safely manipulate resources that aren't accessible to the rest of the program. For example: >[the list quoted above]

eru 6y ago

However, if your user agrees to be limited (because it prevents them from making mistakes), we have fairly reliable methods. But yes, they require the user of your library to cooperate.

catern 6y ago

>none of these actually work and none of the implementations you will find in the wild are anything but snakeoil This is wrong. The foundation of the modern web is safe Javascript implementations. BPF/eBPF is another widespread technology using isolation mechanisms like this. All of these techniques work. As I mentioned in the very next sentence, only the first in that list is common, but that doesn't mean the rest don't work. If you have found some fundamental hole in NaCL or CHERI or JVM security which makes them ineffective, feel free to publish your results.

bpodgursky 6y ago
I think you are talking about different things. I have absolutely decompiled obfuscated third-party Java libraries, fiddled with a few variables or method signatures, and recompiled + used them. JVM security has nothing to do with this.
- catern 6y ago
  You're correct that obfuscation of Java libraries has nothing to do with Java stack inspection/JVM security... but the latter is what the article talks about and what is cited above, so not sure why you have just now brought up decompiling obfuscated Java libraries, which is, as you say, totally unrelated...
  - bpodgursky 6y ago
    What it says is "Java-style stack inspection can restrict user or library code to deny access at runtime to unauthorized methods.", which doesn't seem true to me, if the user has access to the library binaries. It's very possible for the user to just patch the library and use it however they want. It's possible (although I'm not especially convinced) that you can prevent the user from reflectively doing this at runtime, but that's not the only way to access unauthorized methods.
    - rowland66 6y ago
      Yes, the OP has this backwards. The Java sandbox would allow an application to limit the access granted to a library to protect from a malicious library. It does not protect a library from being used by an application in way that was not intended by the library creator. It is certainly not a means of enforcing a licensing scheme.
      - catern 6y ago
        >It is certainly not a means of enforcing a licensing scheme. Could you explain what gave you the impression that this was about licensing schemes? That was definitely not my intention.
bcoates 6y ago
Huh? NaCL is dead, and as far as I know nothing relies on the JVM sandbox for security anymore (and it was a disaster when they tried). These also rely on wrapping the entire userspace into a sandbox, which is hardly relevant to the libraries vs. services thing. You can't inspect a stack from inside the attacker's process and expect that to do anything at all, let alone control access to a resource.
- catern 6y ago
  >You can't inspect a stack from inside the attacker's process and expect that to do anything at all, let alone control access to a resource. See the article: >If user code is running on a sufficiently advanced platform, one not administered by the user, then a library can safely manipulate resources that aren't accessible to the rest of the program. For example: >[the list quoted above]