[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

[Ron Pressler]

> On 17 May 2021, at 13:47, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
> 
> It is a foundational feature, it has a significant impact on those who adopted it.

True. But the problem is that it also has a significant impact on those who didn’t.

> 
> 
> This is an existing system, your arguments are not relevant as the cost of rewriting millions of lines of code is prohibitively expensive.

I don’t think we’re talking about rewriting millions of lines of code, and the cost of keeping
Security Manager is far greater, anyway. We want to shift the high cost of maintaining the
SM, or something like it, from those who *don’t* want it to those who do, and I think that’s more
than fair.

> 
> My point is that there will be no restriction on the services themselves in the JVM consuming and using the services.  Currently service proxy's are only allowed to contact their originating server and negotiate a few required permissions for their operation.  In future versions of Java without a SecurityManager, they will have no restrictions at all.

I don’t understand this statement. Which JDK-implemented “service proxies” are you referring to that
today implement such a restriction in the JDK?

> 
> Yes, it is the case for software that was designed to use the SecurityManager.   We need to be honest about the impact, yes I understand SecurityManager will be removed, however telling developers their EXISTING software is no less secure is inaccurate.
> 

It is accurate, because if existing software picks a new runtime, then it will have to be modified
in order to run at all, if only to acknowledge it is depending on a deprecated, and later, degraded
feature. This JEP is proposing a responsible mechanism precisely to prevent situations like applications
that do depend on SM for security suddenly become less secure without their knowledge.

> 
> Are you a security expert?  Is this your opinion as a security expert?

I am absolutely not a security expert, which is why I talk to security experts who tell me
they do not recommend the Security Manager as a central security measure.


> 
> Your proposal is quite plain and simple, I don't see how it can be misunderstood, you propose to remove the ability to make stack based domain, access control decisions.

Not the ability, but the built-in implementation.

> 
> These sandboxes you talk of, I have not seen any practical workable solutions, I'm assuming your talking about Intel architecture based Virtual Machines that host an OS, they don't provide dynamic access decisions for Java?  Yes I acknowledge they can do static, but not dynamic performant access decisions.

Depends what you mean by “dynamic.” They do not attempt to provide different access to JDK capabilities
to different code-paths within the same Java process, which is why they are preferable.

> 
> We should just say, that there is no future migration path for existing Java applications that require fine grained access control.

But that is untrue. First, let’s clarify that by “fine-grained access control” you don’t mean the
ability of an application to allow or disallow application-level operations on as fine a level as they’d
like based on, say, user credentials, but on the JDK blocking *JDK-level* operations based on the code
paths that invoke them. Second, while the JEP does not offer a built-in replacement for such a mechanism,
because few people want it and we believe it is not a good path for security for Java these days, 
if you absolutely want such a mechanism, you can inject instrumentation to replace the built-in one
using the Java Agent mechanism, so there is a migration path even for this use case.

That taking this particular migration path rather than opting for other security measures is not trivial
only demonstrates why the Security Manager needs to be removed, as the people paying for that work now
are those who *don’t* want it.

> 
> I think for starters we should discourage those who require fine grained access control from using newer versions of Java that don't implement it.   Then it would be nice for those who would like to help maintain an existing version of Java that does support fine grained access control to do so as a part of the OpenJDK project.
> 
> I don't understand why this is so objectionable?

Because your very specific and FAR from universal definition of “fine-grained access control” does
all the work in this statement. It is not objectionable to say that Java will not provide a built-in
mechanism that filters certain JDK operations based on the code-paths in which they are accessed.

> 
> It really doesn't matter what 99.99% of other people are doing for the 0.01% that use it.  You conveniently plucked these figures out of thin air, a word of advice, it lessens the credibility of your arguments.

It is not my intention to convince you personally that the proposal is justified. If you’d like to see the
proposal amended or withdrawn, it is *your* duty to convince those who made it that it should be. If you
think that their assessment of the current value the SM brings to Java users is incorrect, then it is 
up to *you* to support that. I’m carrying on this discussion in the hope that it might uncover some specific 
point that we’ve missed — precisely because we take it very seriously and don’t wish to brush off anything or
anyone -- not in order to get you to concede anything. For example, you mentioned something about service proxies,
and it would be great if you could explain precisely what you mean.

Sometimes two opposing opinions can be equally reasonable, perhaps based on different values, and yet only one 
can be made. It is never our intention to get universal consensus for every decision concerning such a large 
ecosystem, or we’d never get anything done.

— Ron