How to implement security with enabled liveConnect

[rPraml]

Rhino is often used with enabled liveConnect (ImporterTopLevel) that provides access to all java classes.

But this opens big security issues, as soon as the user can enable custom javascript code.

If this is a multi user web application, one user can quit the JVM by just typing java.lang.System.exit() or overwrite files, performing network IO and so on.
See comments in: #972 (comment)

I've experimented with a securityManager (see #861) to restrict IO in (untrusted) javascript.
Unfortunately, the security manager is deprecated with Java 17 https://openjdk.java.net/jeps/411 (but still functional) and will probably removed with Java 18. As far as I see, there is no alternative to restrict file IO and so on.

There is demand to provide some security in LiveConnect. But the current possibilities with ClassShutter or custom wrap factories are limited. You may have access to a class that seems to be harmless, but you've overseen that one of the methods may perform file IO (See PDDocument in this #972 (comment))

This makes it very hard for developers to build an application that is secure.

What are the options:

• Should we / I continue to implement the "sandbox" and use the deprecated SecurityManager and wait until an alternative is provided (which may never be the case). This means, we will loose compatibility after Java 17.
• Should I disable liveConnect (especially loading additional classes) in my application.

If later, there should be a statement in the rhino documentation, that with liveConnect a perfect security is not possible.

[p-bakker]

Case with related questions: #861

[gbrail]

Sorry I didn't answer this before -- I have been in and around some projects that embed Rhino in the past and some that still do.

There are obviously bad things that can happen if you let users supply their own code for Rhino to execute in any environment that you own.

By default, Rhino has no built-in APIs that can do anything other than manipulate what is inside the world of Rhino. If Rhino is initialized using InitSafeStandardObjects, then the main risks in this situation are:

A) A script could allocate a huge amount of memory
B) A script could allocate tons the CPU, or even sit in an infinite loop

(You can reduce or maybe eliminate the risk of B using the "InstructionObserverThreshold" feature of the Context object in conjunction with compiled code. That lets you set a timer, so that if a script runs for too long, or is stuck in one place for too long, you can throw an exception.)

If you allocate the Global object (from the "tools/shell" package) and put it on the context, then now a script can also:

C) Read any file, or execute any program

If you use the regular "InitStandardObjects" function, which enables the Java embedding stuff, then a script can also:

D) Load any Java class that it can and call any Java functions that are accessible

The safest way to avoid all of this would be to put each of your "users" in a sandbox -- not a JVM sandbox, but an OS sandbox, such as a separate Docker container (or some other kind of container) or virtual machine. Then the worst thing that they can do is trash that sandbox, and you can use various mechanisms to limit the impact of A-D above.

If you don't use Global, and then D is the main risk, then it is indeed up to the Java security manager. I think that the Java community is generally pretty skeptical that you can use that to make everything OK, but I'm sure that it helps.

So perfect security is NEVER possible with anything, and certainly not with Rhino, but depending on what you do there are ways to reduce the risk quite a bit.

In my non-security-expert opinion, I think that giving untrusted or semi-trusted users the ability to load anything using LiveConnect is something to avoid. I think you're better off creating specific native classes using one of the other embedding options that interface with your Java code. I think that might be better for your users as well, since you have given them only a JavaScript API, rather than a JavaScript engine that executes code that looks like JavaScript but also works a bit like Java at times!

[tonygermano]

I think running user scripts in a sand boxed OS container is a good solution for the problem. This introduces some new problems, not in Rhino, but for the implementer, in that the code will be running in two separate JVMs with no shared memory, so there will need to be devised some form of serialized message passing to send the script and execution environment to the container and receive the result or updated values back.

[rPraml]

Thanks for your feedback. I read a lot about JEP411, for example
https://www.mail-archive.com/[email protected]&q=subject:%22JEP411%5C%3A+Missing+use%5C-case%5C%3A+Monitoring+%5C%2F+restricting+libraries%22&o=newest&f=1
and there are others that rely on SecurityManager.

I understand the pros and cons, but in the moment I'm afraid that the SM will be removed without replacement.
That's why I sorted out things here to be prepared for JEP411: #1068

By default, Rhino has no built-in APIs that can do anything other than manipulate what is inside the world of Rhino. If Rhino is initialized using InitSafeStandardObjects, then the main risks in this situation are:
A) A script could allocate a huge amount of memory
B) A script could allocate tons the CPU, or even sit in an infinite loop

This would be also true for normal java code, if the code isn't allowed to do native calls. So putting a gate keeper before each native call will keep your system safe. (This is roughly the same, what the current security manager does)

So maybe there IS hope for an alternative.

The safest way to avoid all of this would be to put each of your "users" in a sandbox -- not a JVM sandbox, but an OS sandbox, such as a separate Docker container (or some other kind of container) or virtual machine. Then the worst thing that they can do is trash that sandbox, and you can use various mechanisms to limit the impact of A-D above.

yes of course, but it is not easy to share objects across such instances (without opening new security holes)

So perfect security is NEVER possible with anything, and certainly not with Rhino, but depending on what you do there are ways to reduce the risk quite a bit.

I agree, the securityManager helps and provides 99% security (I had blocke files etc.) but I'm not sure, if I missed a thing.

In my non-security-expert opinion, I think that giving untrusted or semi-trusted users the ability to load anything using LiveConnect is something to avoid.

After an internal discussuion, we decided to be more restrictive this way. So only real trusted users can enter or change javascript where LiveConnect is enabled.