OpenJDK Authorization

Looking for interested parties to assist maintaining a fork of OpenJDK with authorization. Note this isn't for sandboxing untrusted code but instead only allow loading trusted code and automate generation of principle of least privilege policy files for auditing with user Principal's and Code Signer's.

Two things:

Are you planning on getting the TCK so your JVM will be trustworthy to run in prod?

Are you going to backport these changes to all the concurrent releases, or do potential consumers have to "ride HEAD" to use your JVM? Based on the number of "we're still on Java 8" comments that always show up in any JVM submission, I'd guess one would want to be mindful of the versions their audience requires otherwise it's basically your own private fork

Since I am not the target audience for this, pardon me if this seems like a silly question, but wouldn't just using a custom ClassLoader or even an Agent get this done, without having to full-on fork the JDK?

Fascinating effort! I'm just curious, whats the real world use case? I typically don't do any dynamic loading of executable code in my environments.

How much does TCK cost again?

This project looks like it's trying to conserve the old SecurityManager (from the Java Applet/Webstart days) implementation that's been removed from the OpenJDK tree. The motivation is on the website: only a very small number of people still use this, but if you're one of them and have a legacy application that depends on the old behavior you don't want too many changes.

What are use cases for handling the authorization at the JVM level?

As opposed to do it at the OS level or platform level e.g., SELinux, AWS security policy

The JVM has a lot of modules and powerful features that, should perimeter defences fail, an attacker has access to. Then there's the issue of vulnerabilities in transitive dependencies upon which trusted libraries might depend, but aren't needed for deployed software, additional functionality which may be useful to an attacker. Features our software doesn't utilise may be available to a hacker to load dynamically, once perimeter defences have been breached or assist the attacker in breaching perimeter defences.

We may need to give the JVM access to keystores and private information that, should an attacker obtain them, have significant consequences. This isn't going to be the case for everyone, we have software that doesn't utilise SM authorization.

Java's existing SM infrastructure doesn't prevent loading modules or jar files based on signers, nor does it perform whitelisting of serializable classes. I've added LoadClassPermission to SecureClassLoader and SerialObjectPermission to Serialization. Java has serial filters for whitelisting, but these suffer the same problem as SecurityManager did, limited tooling to support building the whitelist. These new permissions allow policy to control loading of modules, including platform modules, based on Signer certificates etc and Serialization whitelists. The Serialization whitelist includes the code on the stack, and the authenticated user. Without the authenticated user (the source of the data), the code alone doesn't have permission to deserialize, the user, cannot deserialized with unauthorized code.

We developed high scaling policy providers (used for over a decade in production), that utilise immutability and thread confinement, we also developed a security manager with a non-blocking cache (cleaned by garbage collection), to avoid repeated permission checks from executor tasks and such like.

I've added these high-performance implementations.

However, the main feature is a principle of least privilege policy tool, with the following property -Djava.security.manager=polpAudit, The JVM will generate policy files, from least privilege principles, including execution paths with code signers, logged in users and serialized classes. This step is performed in a deployment staging environment.

When ready to deploy to production, simply set the property back to -Djava.security.manager=default and the JVM will now use high performance implementations, feel free to try it, the performance cost is unnoticeable for the majority of tasks, keep in mind the cache and hotspot will need time to warm up.

This isn't for sandboxing untrusted code; it's for constraining execution to trusted code and users and assisting in auditing. This isn't your old security manager you used for Applets, we're discarding the cruft and reusing the good.

The goal is, make it simple and practical to deploy a JVM with Authorization.

Answers to other questions:

There are no plans to backport to earlier releases, we'll follow OpenJDK's release cycle.

I have submitted a request for a TCK license.

It requires low level hooks and support from within the JVM, using agents is brittle and difficult to secure, the simplest solution is just to fork. I did spend some time investigating these methods before making the decision.

https://github.com/pfirmstone/HighPerformanceSecurity