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

Tue May 18 00:11:50 UTC 2021

Your ideas are great in theory, in practice, the problem with your Agent 
proposal is every JVM release needs to be reviewed, and we have to 
review Java's internal implementation code, and understand it in order 
to instrument it.  But I do appreciate you took the time to do your 
homework to make the suggestion.

Maybe if you put hooks (annotations?) into the JVM code, so it was 
easier for agents to know which calls need to be controlled for access 
decisions?   But then if not many people are using it, it will suffer 
neglect.

To answer your use case question below, we use a ClassLoader and 
ProtectionDomain, to represent the remote server Subject, this is not 
for authentication, just for access control.  JAAS is used for 
authentication of TLS endpoints.   For services, the calling Subject is 
run in the context of the thread on the remote machine for access 
decisions also.

It's your existing userbase with over 50% still using Java 8 that need 
convincing, who will be ultimate judge of the success or failure of this 
decision.

Thanks for your time.

-- 
Regards,

Peter Firmstone

On 18/05/2021 8:16 am, Ron Pressler wrote:
>
>> On 17 May 2021, at 21:46, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
>>
>>
>> Yes, you are talking about those who maintain and develop OpenJDK, but this is only a small proportion of the overall Java developer ecosystem.
> Not at all. I’m talking about the millions of developers who don’t get what they need sooner because the
> OpenJDK’s resources are invested in maintaining components that add little value to the ecosystem.
>
>> No, it's not practical, but there's no viable upgrade path, so our only option is indefinite maintenance of Java 17.
> I’m not going to tell you where to put your money, but writing a Java agent is orders of magnitude cheaper
> than maintaining an eight-million-line codebase indefinitely.
>
>> In a distributed system that uses POJO's and Remote Method Invocation, a proxy is used to invoke methods on an object in a remote JVM or any other language for that matter, operating in another node or process.   The proxy implementation is not known, nor necessarily are it's communication methods until runtime.  It is loaded dynamically.
>>
>> The proxy is trusted code (each implementation has different bytecode), but we wish to run it with principles of least privilege, rather than an anything goes approach.
>>
>> https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEEqMlozJA$
> I’m not sure I understand. If you’re not talking about a JDK mechanism, you can change that mechanism
> to not use the Security Manager, just as JAAS will be changed.
>
>> If the application needs access control, but the Java platform doesn't provide it, and you must remove it for the application to run, then yes, the software will be less secure as a result.  This shouldn't be difficult to understand.
> I understand but disagree.
>
>> No, but it is a useful security layer to control access.
> The utility of *this particular mechanism* does not justify the cost of maintaining it.
> The question isn’t if such a mechanism could be useful or not, but is this the best use of resources to improve security?
> In other words, the choice isn’t between this and nothing, but between this and everything else.
>
>> It is not possible to implement fine grained access control in Java, or as a library, this feature is low level JVM code.
> Again, when you say fine-grained level access control you don’t mean fine-grained level access control but the
> particular features provided by the Security Manager; and those features — at least those you sound most interested
> in — are not low-level JVM code, and can be implemented in Java with a Java agent, at least as an additional, albeit
> imperfect layer of security, if you think this is a worthwhile and cost-effective approach.
>
>> Developers who wish to develop new applications that require access control should do so using another platform, those who have existing software deployments, need to stay on Java 17 for example, indefinitely until EOL.
> I strongly disagree; the Security Manager is not the only — and I would say it’s not even the best — way to
> offer access control. This JEP proposes removing Security Manager. That that implies giving up on access control
> is entirely your insistence on identifying the two. And if the only way you can think of implementing access
> control is with a call-stack code-sourcing mechanism, then I’m afraid other platforms are not going to offer it,
> because they also don’t share the view that this is the best, let alone the only, way to do this.
>
>> New developments that require access control might consider the Microsoft CLR for example, however I'm no expert, there may be better alternatives. https://urldefense.com/v3/__https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEF_yAtVXw$
> .NET have also dropped their analogous mechanism; they, too, have become convinced that different permissions
> to different code *in the same process* is not a the best approach to security today in cost/benefit.
> Erlang, another platform with a strong emphasis on distributed systems also does not provide this mechanism. I am not
> aware of any platform that does.
>
>> To restrict operations to the principle of least privilege.
> The principles are known, but not every additional layer is worth it at any cost.
>
>> The code is not known at compile time, it is dynamic, such that it is only known at runtime, this means that to use the Java Agent mechanism, one must intercept every network and file system access, then try to determine where the call originates, to see whether it can be allowed or disallowed.
> The Java agent can insert the same instrumentation points as the Security Manager in JDK code, and the equivalent
> of protection domains will be determined by the framework and stored and manipulated as ThreadLocals. StackWalker
> provides what you need for determining caller classes.
>
>> There is no feature in Java past release 17 that would interest me enough to perform this amount of work on an existing application, nor would it even be a viable option if I wanted to. So I can't pay for it even if I want to, as it is unaffordium.
>>
> I am sorry, but asking the majority of Java developers who prefer other approaches to pay for it is even less fair.
>
>> I'm looking at how to support existing deployments that utilise existing Java access control features.
>>
>> Your world sounds more of a static compile time, everything is known up front environment, mine is dynamic and flexible and unknown until after a process has been running for some time.
> I think that instead of working on finding alternatives that would make the cost structure of something
> few people want, you’ve decided that the existing mechanism is the only way to do it.
>
>> However I suspect that you haven't got JEP 411 over the line yet and you are worried that open discussion of the issues it causes may stop it, because it impacts something you are trying to implement.   I apologize if this discussion inconveniences you, but it's still relevant and we should be looking at maintaining a version of Java that supports access control for a very long time, not 8 years.
> You have to convince the relevant maintainers, and this discussion does not inconveniences me because I’m just trying to
> see if there’s something we missed. The Security Manager does not harm the development of any one particular feature
> because new features have already largely overlooked it with few people even noticing. It does, however, take a
> significant toll on resources that could be put to better use elsewhere, including features that improve security in
> a more cost-effective way.
>
>> The only other alternatives is either a complete rewrite in another language, or forking Java, but neither seem viable.
> I don’t think this is the only other alternative at all, and repeating this claim is not something that, I think, will
> help delay this JEP. Evidence that thousands of companies rely on the Security Manager for security might, but short of
> that I think your time would be better spent on trying to suggest alternatives to some critical pieces that might be
> acceptable cost-wise.
>
>> I wouldn't recommend a new development that requires access control to consider using the Java platform at this time.
> OK.
>
>> I'm unable at this time to advise where people should look as I'm still in the investigation stage myself.   If someone does know of other platforms that do access control well, please inform me.
>>
> If by “well” you mean the way that you currently do it and you’re not willing to even consider alternative approaches,
> I think you might be disappointed.
>
> — Ron

-- 
Regards,

Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.