-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Boxtin is a very interesting project. It seems like it's the only way forward for reasonable sandboxing on JDK 24+. But as I dig into it I still find the API bit too fine-grained and tedious. This was the same basic problem with the SecurityManager. It seems Boxtin is about denying access to individual methods and constructors. This has always struck me as a bad idea.
Instead we'd like to simply deny any and all access to certain capabilities of the host platform. In this model Plugins (or any code loaded through an "untrusted" Classloader) should have absolutely no access to the System Console (System.out, System.in), no access to the File system, no access to Networking, no ability to create or start (Virtual) Threads. (There'll probably be additional requirements around JavaFX in the future since we also don't want plugins creating new top-level windows or dialog windows.)
Is this sort of "coarse grained" access denial something Boxtin can do?
Does Boxtin analyze the caller stack-frames at runtime to do its security checks?
But I guess what we'd really like to do is prevent certain classes from being loaded at all from a given untrusted classloader. In other words if the untrusted Plugin Classloader A attempts to load the class java.io.File or even java.lang.System we might raise an immediate error. It's less about checking whether individual methods can be called than it is about denying access to entire classes, packages, and modules.
Is this something Boxtin can do?