Security Manager [Was: JEP draft: Prepare to Restrict The Use of JNI]

[Ron Pressler]

> On 8 Sep 2023, at 06:50, Michał Kłeczek <michal at kleczek.org> wrote:
> 
> While I appreciate the motivation of this is different than that of SecurityManager, let’s not pretend we are doing something conceptually different.
> 
> At the end of the day what we are doing is:
> Granting permissions to perform certain actions to specific software components.

That’s correct.

> 
> The difference is that SecurityManager tried to do it in a principled way that covered broader set of use cases.


It certainly covered a broader set of use cases from the security perspective (although not as effectively as more popular security mechanisms), but a narrower set of use cases in terms of integrity. SecurityManager’s ability to offer integrity for complex server-side applications with lots of dependencies was mostly hypothetical in the sense that for every program there may exist (in the mathematical sense) a configuration libraries that correctly enforces integrity, actually constructing such a configuration was practically intractable (certainly without a prodigious and sophisticated use of doPrivileged in all libraries).

The new integrity is just as principled — although the focus is integrity, not security — and it’s cleverly designed in a way that makes it possible for integrity to be provided by default, at least for the platform (something that even turning on SM by default wouldn’t have achieved because of the way it’s designed).

> And while widely considered as unsuccessful, SecurityManager was important in guarding against vulnerabilities (log4shell for example) for people that used it.
> And here we are: we say “SecurityManager is worthless because it is not used”, we dismiss the idea of turning it on by default (which would be painful for sure), but at the same time decide to enforce this pain in a very specific circumstances.

It’s true SM ended up providing little value because it was barely used, but then the question becomes why wasn’t it used? A part of the answer may well be that it wasn’t turned on by default, but even if it was, its design meant that correct use for modern server-side applications would still have been intractable in practice; those who used it often did so incorrectly, and most never bothered. The fact that SM could have blocked log4shell (or even did for a small number of people) only highlights its problem because simpler and easier (and more popular and more robust) security mechanisms actually did block that exploit for many. That you could hammer a nail with a screwdriver isn’t an argument in favour of the screwdriver for hammering nails, and neither is the fact that some have tried and succeeded.

While strong encapsulation isn’t itself a security mechanism — although it is necessary for any robust secure mechanism to be built in Java — its design (which I believe was done over a span of about ten years) does indeed incorporate some of the lessons learned from SM, and adapts them to Java’s modern environment.

— Ron