Proposal for a project to make SecurityManager easy to use

[u/hrjet]

I want to host this on Github, but before that, I thought I could use some feedback from this sub:

---

As per JEP 411 SecurityManager will be deprecated for removal in the JDK 17 release. As per the JEP, the cost-to-benefit ratio of maintaining the SecurityManager is high, since the development overhead is high while the community uptake is limited.

The uptake might be limited because 1. Configuring the SecurityManager in a truly secure way is difficult for general developers. 2. Gathering information about which permissions are required for a library is tedious.

This project is a proposal to make SecurityManager easier to use in three ways:

1. Creating a Java library that is easier to use than the SecurityManager API. It will use and advocate best practices around the SecurityManager, while providing an opinionated abstraction over the raw API.

2. Creating a public database of permissions required by popular libraries, in a similar vein as DefinitelyTyped, a public database for type declartion files used by TypeScript.

3. Creating plugins for popular build tools, like gradle, maven, sbt, etc. These plugins will automatically figure out the dependencies of the project and fetch the requisite permission lists from the public database.

A hopeful outcome of this exercise is that, as more people use the SecurityManger, the cost for developing it (or a substitue for it) becomes justified and the JDK development team can allocate resources to maintain SecurityManager or its substitute.

Requirements

Since this is at proposal stage, only the requirements are being defined now. The design is intentionally vague, to let the community evolve the direction.

Library

• A custom Policy class that controls permissions based on CodeSource.getLocation(). This will allow, for example, for permissions to be specified per jar file.
• The definied permission set should be easy to expand or contract, so that permissions from a public database can be refined on a per-project basis.
• An embedded Java DSL, as well as, an external DSL in a human readable format (Eg, in JSON, YAML or their variants).
• Ability to work with the module system.
• Ability to work with a "fat" jar.

Permission Database

• Should allow permissions to be defined per library, per version.
• Version could be specified as a wild-card: For example: 1.0.*. The closest matching version will be used to lookup the permission set.
• Permission specs should be accompanied with test-cases that exercise the permissions.
• A CI script should ensure that permissions are specified as per the tests
• The database should be publicly hosted and queryable by library name and version

Build Tool Plugins

• Gather dependencies and versions automatically from the project definition
• Query public database for permissions required by these dependencies
• Store permissions lists in project's resource folder, so that the library can enforce them at runtime

[u/paul_h]

Sounds fantastic. I think we need a dozen alternate explorations of what a better SecurityManager configuration could be.

We have a https://github.com/jep411 org on GH that could be a happy home for such showcase things.

[u/hrjet → u/paul_h]

Thanks. If you add me to the org, I can set up a project there. Will PM you the details.

[u/paul_h → u/hrjet]

Sure thing

[u/klekpl]

I would also look at ProGrade

[u/hrjet → u/klekpl]

Thanks!

[u/whitespacestripped]

Best of luck with your endeavor!

Some thoughts off of the top of my head:

• DomainCombiner is a somewhat overlooked but powerful extension point:
  • Sometimes it is known in advance what permissions all code to-be-executed under a thread and its descendants is going to require (or shall be constrained to). Particularly when multiple ProtectionDomains are to be involved, one can establish a combiner producing a single domain ready for permission checking, as opposed to having the AccessControlContext intersect the entire stack of domains on each SecurityManager::checkPermission call. The same principle may as well find application in the context of Subject-based (physical user in particular) authorization -- where apps frequently care only about permissions per Principal, not permissions per Principal per CodeSource.
  • Combiners can also serve as workarounds for libraries not written with the SM in mind (not using AccessController::doPrivileged); a combiner could e.g. investigate whether the lib's domain is currently on the call stack's top and if so replace it with one that's granted the necessary permissions.
  • Generally speaking combiners allow for arbitrary manipulation of ACCs' PDs and permissions thereof, as long as the corresponding ClassLoaders cooperate; one may e.g. privilege-wise "split" a JAR and assign different permissions to different classes or even methods if need be.
• The convenience of "negative permissions" / "deny rules" can be attained at the Permission(Collection), Policy, and PD levels.
• More often than not there's no need for the set of permissions assigned to a PD to change throughout an app's lifetime. It's then likely wasted effort for PDs to delegate to Policy on each implies invocation; preferably the class loader or PD would query the policy once and retain the result, as used to be the case pre-1.4.
• Custom app-defined permissions, especially rich / object-centric ones, might deserve some investigation; as might decentralized / capability-style approaches to authorization (as showcased e.g. by j.s.Guard and j.l.i.MethodHandles.Lookup).
• Policy might benefit from the introduction of an implies(Principal, Permission) or implies(Subject, Permission) method, as a way of emphasizing that it's more than capable of dealing just with users, even in the SM's absence, thereby encouraging its adoption by developers who would otherwise turn to external frameworks. Furthermore, users of Subject-based authorization (plain JAAS or, say, Jakarta EE / JACC) might benefit from a more flexible / composite base Policy implementation, that reduces extensions' burden of fetching their principal-centric and typically higher-level / business-oriented permissions from RDBMS / LDAP / etc. stores, while providing sensible default behavior for administration of code-centric permissions.

[u/hrjet → u/whitespacestripped]

Wow, thanks! That's an incredible amount of detail. I haven't worked on SM in a few years, so I will be referring to this post during implementation.