Usage within a Java VM

[ericbodden]

Hi all. I just started looking into RLBox. I am a big fan of defense in depth and distrustful decomposition, so this looks like a great help. Thanks for providing this!

I have traditionally, however, been working mostly on tooling to support Java developers. This makes me wonder: do you think it would be possible to use RLBox in combination with a Java virtual machine? And if so, what would that take? My guess is that one could not isolate Java libraries without explicit support of the JVM's just in time compiler, but maybe I am wrong. Have you aver given this any thought?

[talg]

Yes! It would be awesome to have RLBox for Java, we would love to see this, and I think it could be pretty high impact both in the mobile space (android) and with large companies serverside. I don't think there is any need to modify the JIT---the work is basically in figuring out how to most seamlessly incorporate an RLBox style mechanism into how people use native libraries already. We have spent a fair amount of time thinking about this and are doing some work on this in another language (not Java) as well, so yeah, we have thoughts about this =) If this is something you would be interested in exploring with us, we should definitely talk!

…

On Sat, Apr 1, 2023 at 5:03 AM Eric Bodden ***@***.***> wrote: Hi all. I just started looking into RLBox. I am a big fan of defense in depth and distrustful decomposition, so this looks like a great help. Thanks for providing this! I have traditionally, however, been working mostly on tooling to support *Java* developers. This makes me wonder: do you think it would be possible to use RLBox in combination with a Java virtual machine? And if so, what would that take? My guess is that one could not isolate Java libraries without explicit support of the JVM's just in time compiler, but maybe I am wrong. Have you aver given this any thought? — Reply to this email directly, view it on GitHub <#51>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADWGVRJQOEOXDVCQIVOK5DW7AKQVANCNFSM6AAAAAAWPS2UXY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[shravanrn]

To clarify, I assume you are looking at what it takes to isolate Java libraries?

• If you are looking to isolate C libraries invoked by JNI, I'd expect RLBox's sandboxing mechanism + types would be a good way to modify JVM implementations to invoke Wasm-sandboxed C libraries safely. I believe there is some cool prior work (Robusta, Arabica) looking at how this sort of modification could be done manually in the JVM for 32-bit platforms.

• If you are looking to isolate Java libraries directly, we could probably use Java generics to build something like RLBox's tainted types (which automatically adjust for Wasm's different ABI, prevent memory safety errors, and provide a incremental migration/untangling of shared data structures). On one had, Java would give us the memory safety for free, so this is super simple. On the other had, building the other two features in Java generics could get tricky as it is not immediately clear that Java generics has some of the features the C++ rlbox relies on.

Anyway, happy to chat more if you want to discuss!

[ericbodden]

Hello. Thanks for the quick response! I would definitely like to isolate also plain Java libraries, not just native libraries. I think a lot would already be gained by being able to have those run in a separate memory space. The taint mechanism I would then see as a nice additional feature. We have built a number of Java taint analysis tools and type systems in the past, so that part I am not worried about. But how could one effectively use RLBox to encapsulate a plain Java library?

[shravanrn]

I think a lot would already be gained by being able to have those run in a separate memory space.

That sounds interesting! A lot of the details in RLBox are tailored to isolating native libraries. These may go away/need modification for this setting. For example, RLBox allows the host to use tainted data coming from the sandboxed library without triggering memory safety bugs in the host app. But, memory safety issues are no longer an issue when a Java host app uses a sandboxed (but buggy/malicious) Java library, so this part goes away. But many other techniques in RLBox are still necessary.

I suspect the best way forward may be to borrow some of techniques like RLBox --- APIs for sandbox allocation, ABI fixes, lazy marshalling, and tainting --- combined with sandboxing/IFC systems that integrate with the JVM (Robusta, Arabica, Aeolus, Co-Inflow) to build something from scratch that is more tailored to the JVM's security model.

[ericbodden]

Yes thanks, that also corresponds to what I was thinking already. Having to modify a JVM is not ideal, of course, but I think one may not get around it. I will look into the projects you suggested. Thanks!