Coarse-Grained Capabilities Use Case

[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?

[broneill]

Boxtin supports coarse-grained access denial. Entire classes or packages can be denied in one step using the "denyAll" operation of the RulesBuilder. Fine-grained "allow" operations can override course-grained denials as necessary.

Boxtin analyzes the immediate caller stack frame at runtime when performing security checks. This is a "shallow" check, whereas the original SecurityManager checked all the stack frames.

The controller you define and pass to Boxtin is in charge of deciding what rules to select, and for which modules. Your controller needs to be aware of the ClassLoaders used by each plugin, and each will have an unnamed module instance which can be used for selecting the rules. The controller can use a set of very strict denial rules for unknown modules.

You can choose to deny access to java.lang.System (as you mentioned), but this might be too restrictive. The arraycopy method is safe to use, and so denying it doesn't seem necessary. The fundamental problem is that many of the core JDK classes weren't organized properly, and so some degree of fine-grained control is necessary at times. Some of the newer features are better organized however, like the java.lang.foreign package.

Defining a safe set of rules is hard, and so I anticipate Boxtin providing various "stock" rules which can be applied with little effort. Currently there's only one of these defined in the RulesApplier class.

By the way, you also mention restricting access to System.out. I originally supported denying access to fields too, but it was only really applicable to the System fields. I dropped it to keep things simple.

[buko]

Boxtin analyzes the immediate caller stack frame at runtime when performing security checks. This is a "shallow" check, whereas the original SecurityManager checked all the stack frames.

Alright, it sounds like Boxtin is doing runtime checks based on the stackframe. I don't think this is exactly what we want. Instead of doing a runtime security check when somebody calls a method on java.lang.System or java.io.File I think we would want to do a "loadtime" check and deny a Plugin Classloader the ability to load these classes at all. If they do try to call any method on these classes or even reference/import these classes at all I would consider it an error and a breach of the Container contract.

I guess while Boxtin is used for doing traditional stackframe-based analysis, I'm more interested in completely deny Plugins the ability to import or even reference certain classes.

I understand reflection exists and understand reflection breaks all these rules. I guess the reason why Boxtin and the SecurityManager chose this runtime, stack-frame analysis approach was simply to safeguard indirect, reflective loading of classes.

You can choose to deny access to java.lang.System (as you mentioned), but this might be too restrictive. The arraycopy method is safe to use, and so denying it doesn't seem necessary.

I think this is okay. I'm fine with denying all access to classes like java.lang.System and providing wrappers to functionality like System.arraycopy. The only real problem with the "class denial" approach are classes like java.lang.Boolean which provide methods like getBoolean that provide access to underlying System Properties.

[broneill]

Unfortunately, an approach which simply denies access to classes using a ClassLoader can be so restrictive as to be mostly useless, as you mention in the Boolean example. The JDK isn't organized well in this regard, but neither are many third-party libraries.

Boxtin performs true runtime checks for so-called target-side rules, but it performs (effectively) static checks for caller-side rules. The outcome is the same, but target-side rules are much safer. The README file discusses this a bit more. When you consider what the caller-side check does, it can have the exact same effect as denying access to a class if so desired. There's no reason to fiddle with the ClassLoader behavior directly to get the desired outcome.

Is there a particular case you're thinking of in which denying access to classes via the ClassLoader is more appropriate?

[buko]

Unfortunately, an approach which simply denies access to classes using a ClassLoader can be so restrictive as to be mostly useless, as you mention in the Boolean example.

It's not that it's useless but I understand that the "Restricted Classloader Approach" is very restrictive and less flexible or thorough as a "Restricted Methods Approach". Still, I think it might work for us. There are two possibilities:

1. A Plugin wants to directly import a restricted class like java.lang.System or java.io.File. In this case it's a hard no. There's absolutely no reason for a Plugin to ever directly access these classes.

2. The Plugin wants to load a plugin-specific library that wants access to java.lang.System or java.io.File. This is indeed a problem as you point out. Most third party libraries are not written in mind of abstracting access to restricted functionality. In this case we would be willing to work with Plugin developers to explore alternatives. If the library is truly required and safe I think we could provide a mechanism to load such trusted libraries in an ancestor "trusted" Classloader that is not as heavily restricted as the Plugin Classloader.

This is a reasonable compromise. Our threat model is more focused around the actual code of the Plugin. I don't see Plugins requiring too many external dependencies. And if they do we'd probably be willing to accept the risk of widely used open source libraries like Hibernate being run unrestricted. (Though this is definitely a risk eg see Log4Shell. Everybody thought Log4j was a widely used and secure logging library until it wasn't.)

The java.lang.Boolean.getProperty problem is a problem. I think plugging these holes in the Java API would require a Boxtin-like code transformation approach. But I don't think these holes are too many...

Is there a particular case you're thinking of in which denying access to classes via the ClassLoader is more appropriate?

I just think the approach is much simpler and manageable. I struggle with the "blacklist certain methods" approach that Java has used in the past. I don't think it's really scalable or usable. The "white list certain methods" is better -- and this is sort of what Java Modules does -- but it's also functionality and complexity we really don't need. We don't ever want to grant a Plugin access to certain methods on java.io.File or java.lang.System. If the Plugin needs to write to the file system or the System Console it must inject certain Capabilities. So we really do want to deny Plugins any and all access to the filesystem, networking, system platform, etc. Hence "Coarse Grained Capabilities".

I thought, based on the name, "Box"tin, that this is what Boxtin was doing in terms of creating Sandboxes for running code. But now I understand that Boxtin is more like the Security Manager. Thanks for all your help.

[broneill]

I struggle with the "blacklist certain methods" approach that Java has used in the past. I don't think it's really scalable or usable. The "white list certain methods" is better

Boxtin supports both modes. If you want to prevent access to the the File class, you simply indicate this with .forClass("File").denyAll(). Want to block the entire package? forPackage("java.io").denyAll(). In fact, when you construct a new RulesBuilder instance, it starts off in in a "deny absolutely everything" mode. Everything must be whitelisted.

So we really do want to deny Plugins any and all access to the filesystem, networking, system platform, etc.

Yes, I want this too. But I also recognize that the JDK isn't organized properly. Ideally, all file stuff would be in a java.file module, and networking in a java.net module. I want to also support the right balance between flexibility and restrictions. I also understand that the set of rules I think are appropriate for my application aren't appropriate in another, hence the customizability aspect.

The name "Boxtin" is a play on words, meaning that it defines a security sandbox. The original SecurityManager also provided a sandbox, as does an approach using a ClassLoader. These are all just different strategies.