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

[Peter Firmstone]

Some quick clarifications, I'll try to reply properly in the next few days.

On 17/05/2021 9:29 pm, Ron Pressler wrote:
>
>> On 17 May 2021, at 06:19, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
>>
>>
>> In versions of Java, without a security manager, the third party service provider will have AllPermission, and the user will have restricted permissions (if we still have some form of user Permission based access control).
> Follow this issue: https://bugs.openjdk.java.net/browse/JDK-8266592


Thanks for the link, I am aware of it.

>
>
>> So basically we might as well remove all access control completely and say that all users and all code is completely trusted,
> All users — no, and at this point I’m starting to think that, rather than trying to understand
> the direction proposed here, which is ultimately meant to help make Java *more* secure, you’re
> trying to intentionally misunderstand and/or misrepresent it.

I understand the direction and the reasons for the decision, however we 
still need to consider how it will impact those who utilise it, and I'm 
sure more examples will come to light in time.

In my case, yes of course it will be less secure, because I'm using the 
stack context to manage access decisions for remote service identity.   
These service proxy's now have some very limited permissions, in future 
their access will be completely unrestricted.   It is a foundational 
feature, it has a significant impact on those who adopted it.


>
>
>> It does appear that a side effect of JEP 411, perhaps even an unintended consequence, will be to limit Java to trusted networks with one administrator.  It is most certainly appears to be a single JVM focused change, or a system controlled by one administrator.
> Absolutely not. 99.99% of secure distributed systems in the world, written in Java or not,
> do not use Java’s Security Manager, and a great many of them mix of Java and other runtimes.
>
> You might have a point, though, that the current direction does not try to tailor a specific
> solution to distributed systems made *only* of JVMs, and, because systems are not controlled by
> one administrator, and because many are polyglot, mixing services running on different runtimes,
> this is very much the right direction to go. You, on the other hand, seem to be focused on
> “Java only” systems.

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

Services written in other languages may be providers of services, 
however other language runtimes may not be consumers of services because 
most lack dynamic class loading or dynamic fine grained access 
control.   The JVM is required to allow services to be agglomerated into 
a system.

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.


>
>
>> Newer versions of Java will of course be less secure without access controls and unsuitable for use in a distributed system that involves more than one administrator.
> Of course not.

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.


>
> I realise you’re trying to paint a picture as if the removal of Security Manager, a barely used
> component, would adversely affects Java security — contrary to the opinion of security experts — b
> ut the fact is that the vast majority of Java systems today already use other security
> measures, including sandboxes. I don’t know if you actually believe this, in which case you
> misunderstand the proposal, or don’t believe it but think that such claims would sound convincing
> to others.
>
> It is true that we’re saying to those few remaining people who still depend on Java’s internal
> sandbox to do what most other people have already done and rely on other security measures, and so
> *if they do not* their systems will be less secure, but, of course, this is not what’s being
> recommended. All this JEP is saying that the JDK itself will not, in the long term, provide this
> particular fine-grained sandbox, and that remaining users should switch to other sandboxes available
> to Java applications.


Barely used or not, it is only fair to acknowledge the impact on those 
who do use it.

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

I don't need a sandbox, I need access control.

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.

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.

I suspect either you don't understand what I'm talking about, or you 
simply don't want to acknowledge it.  I have provided links to fully 
functional software that utilises SecurityManager.

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

It's quite simple really, just be honest.

I've accepted OpenJDK is doing this, I just want you to acknowledge that 
Java in future will be less capable in this respect than the Java of 
today, so that people who might be impacted take it seriously.

What I intend to do about it, is contribute to existing versions of Java 
to prolong their life.

I'm looking for acknowledgement, so that the importance of maintaining 
Java 17 for a long time is understood for existing applications that use 
fine grained access control, which have no other alternatives can 
continue to remain functional and secure, up to date secure.

Hand waving brush off comments don't provide practical workable solutions.

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?

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.

>
>
> — Ron

-- 
Regards,
  
Peter Firmstone