[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
Peter Firmstone
peter.firmstone at zeus.net.au
Mon May 17 20:46:30 UTC 2021
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
More information about the security-dev
mailing list