Using Graal.js 19.0.0 via Scripting in platform/core.network

[JaroslavTulach]

Since #1011 there is a generic way to request a ScriptEngine via Scripting API. This PR brings the benefits of that API abstractions to platform/core.network module while making sure the actual engine used for PAC resolution can be selected by the vendor of a NetBeans Platform based application and properly tested. This balances the plugability with the necessary safety needed while resolving PAC configurations.

The security is achieved by the ALLOWED_PAC_ENGINES branding API. Each vendor of a NetBeans Platform based application is encouraged to enumerate the one(s) engine that is considered trusted. By default we enlist Nashorn, Graal.js and GraalVM:js - all of them tested and to my best knowledge secure. I trust the GraalVM:js engine the most. Why list others? Because the GraalVM:js engine is only provided as an optional module - many NetBeans Platform applications won't have it - then it is natural to fallback to Nashorn (also considered secure at the moment).

Should NetBeans IDE re-brand the ALLOW_PAC_ENGINES value? Possible. NetBeans IDE is known to carry GraalVM:js implementation, so it could allow only its usage while resolving PAC. I haven't done so, but I have written a test in nb/ide.branding module to verify that GraalVM:js is really selected in the NetBeans IDE.

Why use Scripting.newBuilder().build() to create ScriptEngineManager at all? Because various vendors may have different opinion on which engine to use. @matthiasblaesing had a preference for Rhino. OracleLabs require GraalVM based implementation in VisualVM and co. The pluggable nature of the Scripting API allows anyone to hook the preferred engine of choice into own NetBeans Platform based application and then select it for PAC resolution using ALLOWED_PAC_ENGINES branding API.

To achieve the needed safety levels, this PR also upgrades from RC versions of GraalVM libraries to supported 19.0.0 release. Unlike RCs, this version is considered stable. I'd rather see next version of NetBeans using stable version of GraalVM libraries.

[jlahoda]

Well, I don't think "jlahoda" requested the reviews to be split. I think "jlahoda" was trying to say that he has an example where NB open xclock from the PAC script with that patch from Friday, and it still seems to hold (Nashorn is selected to me, not Graal.js, FWIW). There was also an offer to you (and/or Matthias) to propose a venue to discuss that.

…

On Mon, Jan 21, 2019 at 12:00 PM Jaroslav Tulach ***@***.***> wrote: This change was part of #1011 <#1011>, but @jlahoda <https://github.com/jlahoda> and @matthiasblaesing <https://github.com/matthiasblaesing> requested it to be reviewed separately. The code change is simple: Just use Scripting.createManager() to allow access to pluggable JavaScript engines, like *Graal.js*. The NetBeans IDE, by default selects *Graal.js*. Other distributions can register their own scripting engines like Rhino or Nashorn by removing libs.graaljs from their system and providing their own engine. The test is modified to make it pass on JDK11. CC @lbruun <https://github.com/lbruun> ------------------------------ You can view, comment on, or merge this pull request online at: #1092 Commit Summary - Using Scripting API in platform/core.network File Changes - *M* nbbuild/travis/scripting.sh <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-0> (2) - *M* platform/core.network/arch.xml <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-1> (13) - *M* platform/core.network/manifest.mf <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-2> (2) - *M* platform/core.network/nbproject/project.xml <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-3> (18) - *M* platform/core.network/src/org/netbeans/core/network/proxy/NetworkProxyReloader.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-4> (5) - *M* platform/core.network/src/org/netbeans/core/network/proxy/ProxyAutoConfig.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-5> (4) - *M* platform/core.network/src/org/netbeans/core/network/proxy/pac/PacScriptEvaluator.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-6> (2) - *M* platform/core.network/src/org/netbeans/core/network/proxy/pac/datetime/PacUtilsDateTime.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-7> (2) - *D* platform/core.network/src/org/netbeans/core/network/proxy/pac/impl/ClassFilterPacHelpers.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-8> (42) - *M* platform/core.network/src/org/netbeans/core/network/proxy/pac/impl/NbPacScriptEvaluator.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-9> (75) - *M* platform/core.network/src/org/netbeans/core/network/utils/IpAddressUtils.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-10> (32) - *M* platform/core.network/test/unit/src/org/netbeans/core/network/proxy/pac/impl/PacHelperMethodsImplTest.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-11> (6) - *M* platform/core.network/test/unit/src/org/netbeans/core/network/utils/FakeDns.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-12> (32) - *M* platform/core.network/test/unit/src/org/netbeans/core/network/utils/IpAddressUtilsTest.java <https://github.com/apache/incubator-netbeans/pull/1092/files#diff-13> (6) Patch Links: - https://github.com/apache/incubator-netbeans/pull/1092.patch - https://github.com/apache/incubator-netbeans/pull/1092.diff — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1092>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHk8I6jghTyJnNSrkVbkM2Mwrqq1sG-ks5vFZ3QgaJpZM4aKlVz> .

[matthiasblaesing]

@jlahoda if you think we have a security problem, please take it to private@netbeans.incubator.apache.org (and please CC @lbruun), there we can openly discuss whether or not there is one.

[jlahoda]

I don't think we have such a problem now - but we would have it with the original patch here. With the current patch, things are more better, but I am not convinced they are good enough. Jan

…

On Mon, Jan 21, 2019 at 5:27 PM Matthias Bläsing ***@***.***> wrote: @jlahoda <https://github.com/jlahoda> if you think we have a security problem, please take it to ***@***.*** (and please CC @lbruun <https://github.com/lbruun>), there we can openly discuss whether or not there is one. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1092 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHk8BCYGgynnuCZ6hSvaPj9KTkVlcRuks5vFeqBgaJpZM4aKlVz> .

[lbruun]

Overall it looks good to me.

Two comments:

• Graal's readiness for prime time? With this change Graal now becomes the first choice for PAC Evaluator environment. PAC scripts are always pretty simple JS code so most JS implementations will handle PAC scripts well as long as they can handle simple JS constructs (nothing fancy, ECMAScript v3 compliance would probably be sufficient). So even if I've never tried out Graal myself I'm not worried here.
• The code implicitly assumes that the ScriptEngine returned by the Scripting API is "secure by default". (except for Nashorn where an additional step is taken). Is this the case? Does the Scripting API guarantee it will return a sandboxed execution environment no matter the underlying implementation? (apologies, I haven't reviewed the Scripting API part).

[matthiasblaesing]

The changes look ok. I'm still not convinced though, that it is wise to use $arbitrary js engine in a security sensitive environment.

[JaroslavTulach]

* Graal's readiness for prime time? 

I believe Graal.js is the best engine out there.

* The code implicitly assumes that the `ScriptEngine` returned by the Scripting API is "secure by default". (except for Nashorn where an additional step is taken). Is this the case? Does the Scripting API guarantee it will return a sandboxed execution environment no matter the underlying implementation?

It would be great if all the engines were "secure by default". The scripting API could ensure that - then the Nashorn additional step could be moved into the scripting API.

[JaroslavTulach]

After five months I believe I am ready for integration. Please review (again).

1. Meanwhile GraalVM managed to release official stable version - e.g. this PR updates to Graal.js 19.0.0
2. the biggest complain I noticed in previous round of review: we don't want to have an open list of script engines to use for PAC evaluation - addressed by 7a90c43 and ALLOWED_PAC_ENGINES branding
3. the PR contains a fix for networking issues during build - kind of unrelated, but I wasn't able to move on without it: a297bcf
4. the rest of the PR is basically an attempt to make sure Scripting.newBuilder().build() provides consistent engines (Nashorn, Graal.js and GraalVM:js) secured by default
5. profiler.oql is using Scripting as well, but it only runs trusted scripts and thus needs to run in allowAllAccess mode - hence the new API - Scripting.newBuilder().allowAllAccess(true).build()

I hope the review goes well. I'd really like to get this out of my table. I've been playing with JavaScript engines secure integration since December 2018 and it is time to move to something else.

[geertjanw]

Great work. What are some simpler and more complex scenarios we can use to try this out?

[matthiasblaesing]

I had a very short look at graal.js and it looked much better than Nashorn. At least it brought over the message, that someone cared about security and put thought into it.
I have some doubts, that the Scripting API module is helpful though. It implies that it can do things it won't be able to do. allowAllAccess will only work for Graal.js and nashorn engines. If other engines are used, the user will have a false sense of security, that is not in place. I see, that the ClassLoader magic is helpful here, but is that enough to make it worth it? The Java Scripting API feels ok for trusted scripts, but introduces some doubts when fine grained control over the engine is required.
I'm ok with merging this, but it was only a quick look (I explained on private@ why I won't go deeper).

[geertjanw]

Please do go deeper and please do share your complete feelings, we all need to know fully what the advantages and disadvantages of solutions are, and should wait until you're able to provide that, if you can indicate when/how. I.e., we need you, @matthiasblaesing!

[matthiasblaesing]

Sorry, I will close this matter for me now. Please keep it so.

[JaroslavTulach]

Thanks for your review @matthiasblaesing - I've just rewritten the initial comment in this PR to provide higher level overview of the current state of the PR. Hopefully it addresses some of your concerns.

I have some doubts, that the Scripting API module is helpful though.

Scripting API allows anyone to plug in their preferred engine of choice.

If other engines are used, the user will have a false sense of security, that is not in place.

The ALLOWED_PAC_ENGINES API allows vendor of a NetBeans Platform based application to restrict which engine is used for PAC resolution and thus guarantee the security is in place.

I see, that the ClassLoader magic is helpful here, but is that enough to make it worth it?

There is a lot of JavaScriptEngineTests that check and compare the behavior of all the known engines - Nashorn, Graal.js and GraalVM:js - all of them behave more or less identically and seem to be sufficiently secure. True, the security of Nashorn and Graal.js is achieved by special configuration of the engines via properties, reflection and ClassLoader magic. On the other hand GraalVM:js is configured via public API method calls only. As such I trust it the most and I made it the first choice for PAC resolution in the NetBeans IDE.

However I don't want to restrict freedom of NetBeans Platform vendors. They are encouraged to provide other engines and configure their security before enabling their usage in the ALLOWED_PAC_ENGINES branding API.

I'm ok with merging this

Great. I'll give you guys few more days and then finally close this eight months long endeavor of mine, hopefully.