Open reta opened 2 years ago
Sure, for core may be a niche (not advocating to jump on vt), but we have plugins and extensions (upcoming) - and the folks may start using them
I think the only workable solution is to maintain a downstream fork of OpenJDK that retains and improves existing API's. The question is, are there enough interested parties?
Some thoughts drawn from experiences of practical application of least privileged principles:
The book titled, "Inside Java 2 Platform Security, Second Edition, Architecture, API Design and Implementation" by Li Gong, Gary Ellison and Mary Dageforde, ISBN: 0201787911, provides insight into the concepts and thoughts of the original designers.
JEP411 deprecates for removal, Java platform support for Authorization and delegates responsibility to the underlying OS, without proposing any replacement API's to assist developers to do so. The wording of JEP411 confounds and confuses security principles, its criticism of the Java Platform's Security Architecture and API Design can be explained entirely by its complete and total lack of tooling around policy files and poorly maintained and under-developed implementations, which are easily replaced using service providers.
Fundamental principles of security:
Each compliments the other, remove any one and system security is deficient.
After exploring all other options it's my conclusion that the only workable way possible to "Replace Java Security Manager", is to maintain a downstream fork of OpenJDK that retains support for Authorization.
Instead of reimplementing, it is far less work to fix and improve it.
How can Java Platform Security be improved, for the benefit of those who are not security fluent but are required to action it?
The principle of least privilege simply doesn't grant any more permission than that which is required to perform specific tasks, policies are updated when new tasks are added.
Something I'd like to mention too, SecureClassLoader (a parent class of URLClassLoader) uses URL as a key in a map, which calls DNS, might this be used in a gadget attack with DNS cache poisoning to load foreign code? In JGDMS there's an RFC3986 URI class loader, that uses normalized URI identity and doesn't call DNS. We have a URL scheme with a SHA256 or SHA512 message digest that checks that the bytes haven't been manipulated prior to class loading, we also have permission checks to prevent unauthorized class loading.
Default CodeSource implies and equals calls also call DNS, we don't use these in our permission checks, we use RFC3986 normalized URI instead.
There are many ways that OpenJDK security could be improved.
We prevent loading agents now using our policy tool, if agents are needed, then why not have authentication and authorization checks in place, the above JEP seems like a brittle solution to me?
I really don't see any existing mechanism to move forward away from JSM other than to stop relying on JSM or similar mechanism altogether. If one can install custom code in the cluster, assume that code must be fully trusted. I would rip out JSM without a replacement in a major version breaking change and add the ability to run code remotely or in a separate JVMs as sandboxed or untrusted using the mechanisms introduced in https://github.com/opensearch-project/opensearch-sdk-java.
@dblock @reta @pfirmstone @uschindler can you please confirm if this change can be included in 2.x without breaking existing API? Basically can this change be added in a backward compatible manner in 2.x line?
We are evaluating if this change warrants a 3.0 release or can be included in 2.x line so need your inputs.
I don't think we have a path forward for this change, but any version of it cannot be included in a 2.x without breaking backwards compat.
the warnings in JDK-21 are really annoying and seems sooner are the dawn of security manager.
One of the ideas that I wanted to explore was around running untrusted code from plugins within a Web-assembly (WASM/WASI) sandbox. Surely, the hardest [2] and unknown part is "to compile JAVA to WASM".
Thanks @kumargu , we are closely watching [1] as well. WASM aside, GraalVM's sandboxing [2] looks really appealing and it could be worth exploring. On a general note, compiling plugins / extensions to WASM and using them from OpenSearch would largely address the concerns with SecurityManager
removal. Thank you.
[1] https://github.com/oracle/graal/issues/3391 [2] https://github.com/opensearch-project/OpenSearch/issues/1687#issuecomment-1545696833
btw @reta, do you know if everything in GraaVM is free and open-licensed? I have read conflicting answers on internet.
btw @reta, do you know if everything in GraaVM is free and open-licensed? I have read conflicting answers on internet.
Yeah, it is super confusing, but the gist of [1] is:
Oracle GraalVM is free to use in production and free to redistribute, at no cost, under the GraalVM Free Terms and Conditions.
[1] https://medium.com/graalvm/a-new-graalvm-release-and-new-free-license-4aab483692f5
You have to be careful: Lucene is not Graal bullet proof, we don't test it. In addition, all our vector SIMD code is disabled once Lucene detects Graal. The reason is that Graal has no vector incubator support.
You have to be careful: Lucene is not Graal bullet proof, we don't test it. In addition, all our vector SIMD code is disabled once Lucene detects Graal. The reason is that Graal has no vector incubator support.
Absolutely, AFAIK we have never tested OS with GraalVM so this area is full of unknowns
Is your feature request related to a problem? Please describe. It has been announced a while ago that
SecurityManager
is going to be phased out from the JDK. The first step, the deprecation of the SecurityManager (JEP-411), has been landed in JDK 17 and issues the following warnings on OpenSearch builds or server startup:The JDK 18 pushes it even further and now fails on startup (see please https://bugs.openjdk.java.net/browse/JDK-8270380), running OpenSearch builds or server on JDK 18 EA fails with:
It now requires JVM command line option to enable it explicitly using (see please [1]):
Describe the solution you'd like There is no alternative or replacement for the
SecurityManager
(to understand why, Project Loom is to "blame"), see please [2]. One of the options is to just drop it, it sounds risky but combined with Plugin Sandbox (see please [3], [4]) it may sounds like a viable option. Other options include (but not limited to): bytecode instrumentation, java agent, custom classloader.Describe alternatives you've considered We could keep it as long as we can, but once removed from the JDK, it will be a problem.
Additional context See please links.
[1] https://inside.java/2021/12/06/quality-heads-up/ [2] https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ [3] https://github.com/opensearch-project/OpenSearch/issues/1572 [4] https://github.com/opensearch-project/OpenSearch/issues/1422 [5] A possible JEP to replace SecurityManager after JEP 411