3 ms·

Was "tomcat" and EJB the 90s version thereof?

pvg 6y ago
Not really, it would fall under the 'language runtime' category in the article. EJB was not really designed with the goal of isolating entirely arbitrary, intentionally adversarial code. That's a problem that's gone from 'near-future interesting' to 'current, important and practical' since the 90s - both on the client (browsers, phones) and the server.
- pjmlp 6y ago
  Sure it was, that is what I have done several times with WebSphere.
  - pvg 6y ago
    You ran intentionally adversarial code with WebSphere?
    - pjmlp 6y ago
      I run intentionally WebSphere security capabilities to contain EAR and WARs into their own little universe, alongside JEE security capabilites and managers. Everything that Docker sells was already possible with JEE application containers, just Java only.
      - hinkley 6y ago
        To be fair, there were a lot of CVEs because part of the sandbox in Java was capabilities-based, and the Achilles' heel of capabilities is that if you can see it, you can use it, and feature factory work has a bad habit of accidentally making things visible by exposing some parent object in an attempt to be helpful. I did like the permissions inheritance model quite a bit, but the hybrid ACL/capabilities system was always a bit schizophrenic.
        pjmlp 6y ago
        Still way less than C based technology, and besides most of them were related to Java Applets, a completely different stack than application containers like WebSphere.
      - tptacek 6y ago
        No, it wasn't; you couldn't keep code running in a WAR off the network. For a number of years, practically every sitewide pentest I did was gameovered by SSRF off Java application servers. I never even bothered to figure out how tight the isolation between co-resident applications was on those things.
        pjmlp 6y ago
        Sure you can, by packing the network sensitive code into another Java library and using process internal bean calls across domains. Now if those guys didn't understood the WebSphere capabilities that is another matter.
        tptacek 6y ago
        The idea behind sandboxed execution environments is to make them resilient to insecure application code. You can't address that problem by stipulating that your application is secure!
        pjmlp 6y ago
        Neither did I said that, rather that WebSphere does provide the tooling to create such sandboxes, provided one goes through the effort to create the application architecture in a way that those features at put it use. It doesn't do magic if the users don't bother to use the tools put at their disposal. This isn't sandboxing at click of button.
        tptacek 6y ago
        See previous comment.

pvg 6y ago

Not really, it would fall under the 'language runtime' category in the article. EJB was not really designed with the goal of isolating entirely arbitrary, intentionally adversarial code. That's a problem that's gone from 'near-future interesting' to 'current, important and practical' since the 90s - both on the client (browsers, phones) and the server.

pjmlp 6y ago
Sure it was, that is what I have done several times with WebSphere.
- pvg 6y ago
  You ran intentionally adversarial code with WebSphere?
  - pjmlp 6y ago
    I run intentionally WebSphere security capabilities to contain EAR and WARs into their own little universe, alongside JEE security capabilites and managers. Everything that Docker sells was already possible with JEE application containers, just Java only.
    - hinkley 6y ago
      To be fair, there were a lot of CVEs because part of the sandbox in Java was capabilities-based, and the Achilles' heel of capabilities is that if you can see it, you can use it, and feature factory work has a bad habit of accidentally making things visible by exposing some parent object in an attempt to be helpful. I did like the permissions inheritance model quite a bit, but the hybrid ACL/capabilities system was always a bit schizophrenic.
      - pjmlp 6y ago
        Still way less than C based technology, and besides most of them were related to Java Applets, a completely different stack than application containers like WebSphere.
    - tptacek 6y ago
      No, it wasn't; you couldn't keep code running in a WAR off the network. For a number of years, practically every sitewide pentest I did was gameovered by SSRF off Java application servers. I never even bothered to figure out how tight the isolation between co-resident applications was on those things.
      - pjmlp 6y ago
        Sure you can, by packing the network sensitive code into another Java library and using process internal bean calls across domains. Now if those guys didn't understood the WebSphere capabilities that is another matter.
        tptacek 6y ago
        The idea behind sandboxed execution environments is to make them resilient to insecure application code. You can't address that problem by stipulating that your application is secure!
        pjmlp 6y ago
        Neither did I said that, rather that WebSphere does provide the tooling to create such sandboxes, provided one goes through the effort to create the application architecture in a way that those features at put it use. It doesn't do magic if the users don't bother to use the tools put at their disposal. This isn't sandboxing at click of button.
        tptacek 6y ago
        See previous comment.