Skip to content

Coarse-Grained Capabilities Use Case #8

@buko

Description

@buko

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions