All 0 Likes
JEP 411: What it Means for Java’s Security Model and Why You Should Apply the Principle of Least Privilege
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 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.
Interesting read on @foojayio about the current state of the @grailsframework, at @TheASF
Written by @spoole167 interviewing @JamesFredley
https://foojay.io/today/grails-isnt-done-yet-part-1-inside-the-asf-reboot/
#Java 26 is here, and its main purpose is to provide a solid foundation for future things to come. It comes with new features, performance improvements and multiple enhancements–my blog post has all the info! 🚀
My #Java 26 article is now also available on Foojay Today! @foojayio
All 4 Comments