4 ms·

Uh, well the original developers of the Sun JVM didn’t do such a bad job after all when designing it: https://docs.oracle.com/javase/7/docs/technotes/guides/sec

by eecc 6y ago

Uh, well the original developers of the Sun JVM didn’t do such a bad job after all when designing it: https://docs.oracle.com/javase/7/docs/technotes/guides/security/smPortGuide.html https://docs.oracle.com/javase/7/docs/technotes/guides/secur...

WatchDog 6y ago
Javas security manager system, is usually not in effect for the majority of use cases. While maven/grade dependencies, can't run code on installation, generally once the application is ran/tested, it will be with full user permissions, not under a security manager. The security manager is an additional layer of security that most languages don't have, however Java applets have shown it to be full of holes and generally unsuitable for running untrusted code. The applet security posture has contributed a great deal towards negative opinion towards the language, probably would have been better off never having existed.
- mike_hearn 6y ago
  There have been hundreds, maybe thousands of local privilege escalation vulnerabilities on Linux. People still find bugs in basic programs like sudo that have been there for decades. Still, nobody would ever suggest that Linux should have the same security approach as Windows 95 or that it's generally unsuitable for running code you didn't write! Sandboxing code is hard, regardless of what language, runtime or operating system approach you use.
szc 6y ago
The Sun JVM, as originally implemented, can express operations that are not valid for Java objects. There are parts of the JVM that attempt to constrain opcode sequences to only be from "valid java compilers operating on java objects". In 1996, Java was being overwhelmed by exploits because the mapping of the language to the VM was not well matched. There was a Java summit with lots of interesting people. This summit was also when Sun got confirmation that MicroSoft had quite a few engineers working on an independently implemented runtime. To Sun's credit, they did get rather more serious about Java security -- but they had already created a rocky foundation. It is my opinion, that the business model Sun had "in mind" for Java was a free runtime for everyone that they were in control of, but to make money from selling an "official" Java compiler suite. I do not believe that the Sun Java JVM was created with security in mind.

by eecc 6y ago

WatchDog 6y ago

Javas security manager system, is usually not in effect for the majority of use cases. While maven/grade dependencies, can't run code on installation, generally once the application is ran/tested, it will be with full user permissions, not under a security manager. The security manager is an additional layer of security that most languages don't have, however Java applets have shown it to be full of holes and generally unsuitable for running untrusted code. The applet security posture has contributed a great deal towards negative opinion towards the language, probably would have been better off never having existed.

mike_hearn 6y ago
There have been hundreds, maybe thousands of local privilege escalation vulnerabilities on Linux. People still find bugs in basic programs like sudo that have been there for decades. Still, nobody would ever suggest that Linux should have the same security approach as Windows 95 or that it's generally unsuitable for running code you didn't write! Sandboxing code is hard, regardless of what language, runtime or operating system approach you use.

szc 6y ago

The Sun JVM, as originally implemented, can express operations that are not valid for Java objects. There are parts of the JVM that attempt to constrain opcode sequences to only be from "valid java compilers operating on java objects". In 1996, Java was being overwhelmed by exploits because the mapping of the language to the VM was not well matched. There was a Java summit with lots of interesting people. This summit was also when Sun got confirmation that MicroSoft had quite a few engineers working on an independently implemented runtime. To Sun's credit, they did get rather more serious about Java security -- but they had already created a rocky foundation. It is my opinion, that the business model Sun had "in mind" for Java was a free runtime for everyone that they were in control of, but to make money from selling an "official" Java compiler suite. I do not believe that the Sun Java JVM was created with security in mind.