Java, like most platforms or languages has layers of security. This article intends to look at Java’s Authorization layer, which is unlike in other languages.
We will also distinguish between two different ways this layer is typically utilized and why one is effective while the other isn’t.
Furthermore, we investigate why JEP 411 only considers the least effective method and hopefully we will increase awareness of the Principle of Least Privilege as it is applied to Java Authorization, improve adoption and encourage people to take advantage of the improved security it provides.
We hope to prolong its support and possibly even improve it in future.
-
The Principle of Least Privilege and How JEP 411 Will Have a Negative Impact on Java Security
The SecurityManager and associated infrastructure are the foundations upon which to build secure software, but by themselves are insufficient for limiting users and Java software to the principles of least privilege.
JEP 411 removes the SecurityManager and AccessController.
In doing so, your library code will be able to run with the full permissions of its Java process, which is the same as running with none of the permission checks that were used to harden Java’s API.
If an attacker breaks into your Java process via some other vulnerability, they will be able to load their own byte codes, and pretty much do whatever the process permissions permits them and possibly more if your system has other vulnerabilities.