4 ms·

no, not just applets. its used for any kind of secure system where developers and their components are forbidden from say network access, e.g. some nashorn map

no, not just applets. its used for any kind of secure system where developers and their components are forbidden from say network access, e.g. some nashorn map reduce javascript. java _used_ to be the language of choice for building complex systems with large multinational multidisciplinary teams. security manager was a vital part to those projects, removing security manager means none of that can migrate. why do it?

derefr 5y ago
Because the modern Enterprise-y best-practice is to not allow multiple security contexts to exist within a single monolithic OS process where the OS kernel's own "security manager" can't get to them to enforce its own policy; but rather to cleave apart your process along security-context lines into multiple processes; containerize those to isolate them from each-other; poke precise holes in those containers for well-defined RPC channels to flow; and connect those channels using a service mesh with secure application-layer firewalling. No modern ops staff would trust the JVM to not be exploitable if you're exposing it as an attack surface to arbitrary user-supplied (or "third party dev who is incentivized to make a network call you don't want them to make") bytecode. Creating that kind of boundary is what technologies like gVisor and Istio are for; it's not the job of a programming-language runtime. (See also: the decline and fall of Google App Engine's "secure runtime" standard environment, in favor of the gVisor-based flexible environment.) (Well, okay, Node and Lua are both runtimes that have trustworthy VM-level isolation that can be used to achieve this — see Cloudflare Workers for the Node case, or Redis scripting for the Lua case. But this is because Node and Lua both have "shared-nothing" runtime execution semantics with no concept of static-bound identifiers [i.e. constants] — meaning that all the fundamental "stuff" available in a Node or Lua execution context is put there dynamically, and so a sandbox can be constructed "from scratch" with arbitrary stuff [mocks/stubs/proxies] inserted in place of the fundamental module handles, to create a whitelisted environment. The JVM is not built like this; the JVM's Security Manager merely blacklists certain known-dangerous operations, and so does nothing to prevent exploitation of zero-day vulnerabilities.)
- kentonv 5y ago
  > Node and Lua are both runtimes that have trustworthy VM-level isolation that can be used to achieve this — see Cloudflare Workers for the Node case Correction: Cloudflare Workers does not use Node, explicitly because Node does not provide secure isolation. Workers uses a custom runtime built directly on V8, which does provide secure isolation in the way you describe. As for Lua, it might work in theory, but I don't think it has had anywhere near the scrutiny V8 has had. I wouldn't bet on it when security really matters.
  - derefr 5y ago
    Thanks for that detail. Re: Lua, I don't know about "scrutiny" in the code-audit sense, but I believe that there are a few battle-tested deployments of Lua in entirely-untrusted sandboxing use-cases. Some games (e.g. Minecraft's Computercraft mod) allow players to deploy arbitrary Lua scripts which are then executed on other arbitrary players' computers; and yet nobody's managed to nuke anyone else's hard drive through these scripting mechanisms yet, despite griefers having high motivation to try. For the same reason that blockchain software continuing to exist makes me have a lot more faith in the collision-resistance of SHA256 (despite a lack of cryptanalytic proof of such), I'd trust a tightly-constrained Lua sandbox. (In both cases, of course, there might be a state-military-level adversary with a vulnerability in hand, who doesn't want to show their hand for something as trifling as money. But such an attacker is highly unlikely to deploy their exploit against my service in particular, even if they have it.)
- DarkmSparks 5y ago
  None of that explains why java breaking tried and tested existing solutions is a good idea for anyone.
  - derefr 5y ago
    Because nobody is maintaining it, because nobody is using it in big modern projects; and a blacklist-based solution like the Security Manager needs constant attention and maintenance as the JVM's stdlib grows, to avoid something slipping through. Every time someone adds something that needs to be secured to the JVM, there's the extra overhead of coming up with a (not necessarily easy!) way of instrumenting it for the Security Manager to control. Given a fixed pool of developer resources, eliminating unused per-change overheads like this, serves as a multiplier for the project's ability to do everything else. The time freed from core devs by not writing Security Manager instrumentation for everything, could be instead allocated to e.g. getting Project Loom stable and upstreamed. And that's assuming that everyone even does the Security Manager instrumentation of each new thing perfectly. The devs doing that instrumentation don't use Security Manager any more than a random Java dev does, so they likely don't know its ins and outs. Every new patch is thus a new opportunity for someone to bungle the Security Manager instrumentation, and thus for exploitable JVM surface area to be created. The more time that goes by, the more likely such exploitable surface area is to have already been introduced and gone entirely unnoticed by a population of developers that just doesn't use the feature. And so, the more time/patches that go by, the more that the Security Manager shifts from being a harmless thing to leave around, to a land-mine waiting to strike any dev who does try to use it. (The "blacklist where at any point a new feature could be added and its security implications missed" problem is the same reason it's hard to trust SELinux—but at least SELinux is used by default for securing system components in some Linux distros, so at least SELinux policies gets pulled in on a regular basis as part of other companies' security audits of their stacks. Security Manager isn't used by default anywhere!)
krzyk 5y ago
nashorn is no more in JDK

derefr 5y ago

Because the modern Enterprise-y best-practice is to not allow multiple security contexts to exist within a single monolithic OS process where the OS kernel's own "security manager" can't get to them to enforce its own policy; but rather to cleave apart your process along security-context lines into multiple processes; containerize those to isolate them from each-other; poke precise holes in those containers for well-defined RPC channels to flow; and connect those channels using a service mesh with secure application-layer firewalling. No modern ops staff would trust the JVM to not be exploitable if you're exposing it as an attack surface to arbitrary user-supplied (or "third party dev who is incentivized to make a network call you don't want them to make") bytecode. Creating that kind of boundary is what technologies like gVisor and Istio are for; it's not the job of a programming-language runtime. (See also: the decline and fall of Google App Engine's "secure runtime" standard environment, in favor of the gVisor-based flexible environment.) (Well, okay, Node and Lua are both runtimes that have trustworthy VM-level isolation that can be used to achieve this — see Cloudflare Workers for the Node case, or Redis scripting for the Lua case. But this is because Node and Lua both have "shared-nothing" runtime execution semantics with no concept of static-bound identifiers [i.e. constants] — meaning that all the fundamental "stuff" available in a Node or Lua execution context is put there dynamically, and so a sandbox can be constructed "from scratch" with arbitrary stuff [mocks/stubs/proxies] inserted in place of the fundamental module handles, to create a whitelisted environment. The JVM is not built like this; the JVM's Security Manager merely blacklists certain known-dangerous operations, and so does nothing to prevent exploitation of zero-day vulnerabilities.)

kentonv 5y ago
> Node and Lua are both runtimes that have trustworthy VM-level isolation that can be used to achieve this — see Cloudflare Workers for the Node case Correction: Cloudflare Workers does not use Node, explicitly because Node does not provide secure isolation. Workers uses a custom runtime built directly on V8, which does provide secure isolation in the way you describe. As for Lua, it might work in theory, but I don't think it has had anywhere near the scrutiny V8 has had. I wouldn't bet on it when security really matters.
- derefr 5y ago
  Thanks for that detail. Re: Lua, I don't know about "scrutiny" in the code-audit sense, but I believe that there are a few battle-tested deployments of Lua in entirely-untrusted sandboxing use-cases. Some games (e.g. Minecraft's Computercraft mod) allow players to deploy arbitrary Lua scripts which are then executed on other arbitrary players' computers; and yet nobody's managed to nuke anyone else's hard drive through these scripting mechanisms yet, despite griefers having high motivation to try. For the same reason that blockchain software continuing to exist makes me have a lot more faith in the collision-resistance of SHA256 (despite a lack of cryptanalytic proof of such), I'd trust a tightly-constrained Lua sandbox. (In both cases, of course, there might be a state-military-level adversary with a vulnerability in hand, who doesn't want to show their hand for something as trifling as money. But such an attacker is highly unlikely to deploy their exploit against my service in particular, even if they have it.)
DarkmSparks 5y ago
None of that explains why java breaking tried and tested existing solutions is a good idea for anyone.
- derefr 5y ago
  Because nobody is maintaining it, because nobody is using it in big modern projects; and a blacklist-based solution like the Security Manager needs constant attention and maintenance as the JVM's stdlib grows, to avoid something slipping through. Every time someone adds something that needs to be secured to the JVM, there's the extra overhead of coming up with a (not necessarily easy!) way of instrumenting it for the Security Manager to control. Given a fixed pool of developer resources, eliminating unused per-change overheads like this, serves as a multiplier for the project's ability to do everything else. The time freed from core devs by not writing Security Manager instrumentation for everything, could be instead allocated to e.g. getting Project Loom stable and upstreamed. And that's assuming that everyone even does the Security Manager instrumentation of each new thing perfectly. The devs doing that instrumentation don't use Security Manager any more than a random Java dev does, so they likely don't know its ins and outs. Every new patch is thus a new opportunity for someone to bungle the Security Manager instrumentation, and thus for exploitable JVM surface area to be created. The more time that goes by, the more likely such exploitable surface area is to have already been introduced and gone entirely unnoticed by a population of developers that just doesn't use the feature. And so, the more time/patches that go by, the more that the Security Manager shifts from being a harmless thing to leave around, to a land-mine waiting to strike any dev who does try to use it. (The "blacklist where at any point a new feature could be added and its security implications missed" problem is the same reason it's hard to trust SELinux—but at least SELinux is used by default for securing system components in some Linux distros, so at least SELinux policies gets pulled in on a regular basis as part of other companies' security audits of their stacks. Security Manager isn't used by default anywhere!)

krzyk 5y ago

nashorn is no more in JDK