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

[Peter Firmstone]

On 18/05/2021 12:25 am, Ron Pressler wrote:
>
>> 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.


Yes, you are talking about those who maintain and develop OpenJDK, but 
this is only a small proportion of the overall Java developer 
ecosystem.    But I understand that this isn't insignificant either, 
just like the features removal isn't insignificant to those affected by it.

Out of curiosity, was anyone here impacted by the oil pipeline shutting 
down?   Impacts can be direct and indirect.


>
>>
>> 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.


No, it's not practical, but there's no viable upgrade path, so our only 
option is indefinite maintenance of Java 17.


>
>> 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?


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://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS


>
>> 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.


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.

So you could say, that the application has become less secure, with 
their knowledge, because it has a task to perform and it will be made so 
that it will continue to perform that task, even at the expense of less 
security, because security has become the obstacle to operation, which 
is the primary purpose, so security becomes a secondary concern.  No one 
will switch it off if it's insecure, at least not until after they're 
hacked, then they'll look for bolt on security solutions and they may 
get approval to rewrite the system at that stage.


>
>> 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.


No, but it is a useful security layer to control access.

Security should be seen as a layered approach, rather than one solution 
fits everything.   Each layer has it's role to play.

The use of SecurityManager as a central security measure is not the intent.

https://www.upguard.com/blog/principle-of-least-privilege

Yes the Java Permission model is flawed, one cannot disallow an insecure 
network connection, while allowing a secure TLS authenticated 
connection, however we've created other ways of doing that, but it does 
rely on the Permission model to limit privilege.


>
>
>> 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.


It is not possible to implement fine grained access control in Java, or 
as a library, this feature is low level JVM code.

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.

New developments that require access control might consider the 
Microsoft CLR for example, however I'm no expert, there may be better 
alternatives. 
https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/


>
>> 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.


Dynamic means at runtime, not compile time or installation time.

We did look at using a separate process to sandbox untrusted code, but 
it just didn't seem like a good idea to allow untrusted code to run at 
all, at least not dynamically, one should run static analysis on it 
first, but if it's a black box, you can only inspect bytecode, not 
source and it can be obfuscated.

This is why authentication is still important, but even that can be 
circumvented by a good attacker and shouldn't be relied upon as the only 
defense.


>
>> 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.


To restrict operations to the principle of least privilege.

https://us-cert.cisa.gov/bsi/articles/knowledge/principles/least-privilege

https://www.upguard.com/blog/principle-of-least-privilege

It would have been better if we could have assigned principles of least 
privilege to Java library's too.

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.

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.

Besides we know what runs now is very performant, high scaling and 
concurrent.   It  also runs with the principles of least privilege, so 
if someone makes a coding mistake, it will be more difficult for an 
attacker to take advantage of.



>
>> 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.


As you say, it's a small segment of the development base that needs this 
feature, we should advise them to use a platform that supports it, 
rather than try to get Java to do such things by bolting it on as an 
afterthought.   Security added later doesn't work, it needs to be 
considered at the design stage.

https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/


>
>> 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


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. The bytecode we wish to manage 
access control of, may be written years after an existing deployment has 
been running, we don't need to shutdown that deployment, or forklift 
upgrade it, we simply add the new components, or nodes and they are 
discovered dynamically at runtime and become an integral part of the 
system automatically.

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.   As part of this JEP or make 
removal of the SecurityManager and associated components dependent on 
another JEP that proposes maintaining a version of Java 17 for the 
foreseeable future.   This would be community supported version by those 
who require it, maybe we can backport some things in later versions. 
Simply because access control cannot be implemented as a library feature 
or bolted onto the JVM as an agent instrumenting unknown bytecodes.

The only other alternatives is either a complete rewrite in another 
language, or forking Java, but neither seem viable.

I wouldn't recommend a new development that requires access control to 
consider using the Java platform at this time.  As you say, it is only a 
small number of developments, but they should look elsewhere.

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.

-- 
Regards,
  
Peter Firmstone