A possible JEP to replace SecurityManager after JEP 411

[David Lloyd]

Hi Sean, thanks for replying. I'll reply inline.

On Thu, Apr 7, 2022 at 2:20 PM Sean Mullan <sean.mullan at oracle.com> wrote:
>
> With this proposal, as I understand it, the JDK would still be
> responsible for maintaining and preserving essentially all of the
> existing calls to the Security Manager (SM).

I think we'd actually want to evaluate each case to decide whether to
retain the permission check. But I didn't want to preemptively
eliminate any check, especially considering that the `Permission`
classes were not included in JEP 411.

> All new code and APIs would
> still need to be evaluated and determined if permission checks were
> needed as well as making appropriate specification changes to note the
> behavior when an SM is enabled (throwing a SecurityException, etc).

Correct.

> Any missing checks would need to be treated as security issues.

This I disagree with: we are not proposing retention of this API for
sandboxing purposes. In fact the only reason to keep the name
`SecurityManager` is for compatibility purposes.

Instead the API would exist to give containers and applications an
extra layer of authorization which does not exist today.
Hypothetically speaking, if even one authorization check is retained,
then that is more than would exist if the API were removed. There
would be no expectation that usage of this API conveys any kind of end
to end security, and this would be explicitly conveyed in the API
documentation.

> And we would
> still need to test the code and APIs to ensure that it worked properly
> and complied with the API specification. This would likely mean
> implementing and maintaining an internal SM implementation in OpenJDK.

Only within the test suite, and this would be expected to be trivial
implementations only: always allow vs always throw.

> The proposal also includes retaining calls to doPrivileged (but later
> potentially replacing them with some other mechanism TBD).

No, this is incorrect; the proposal includes retaining the *methods*,
not the calls; this is explicitly left off of the proposal.

> The JDK source code includes over 1000 calls to doPrivileged. Each of these need
> to be carefully reviewed to ensure that they do not contain security
> issues and any new code needs to be evaluated to see if new calls to
> doPrivileged are necessary.

Under this proposal, it would be perfectly acceptable to eliminate
these calls, and put the onus on the implementation to decide the
circumstances of the invocation. The JDK would be under no obligation
to provide any level of actual security - it would only be obligated
to use the installed SecurityManager, if any, for authorization checks
at some subset of the locations at which an authorization check
currently takes place.

> Retaining doPrivileged (or something similar) means that there can be
> domains of code with different permissions running within the VM, which
> retains much of the complexity of the current SM model.

The only reason to retain these methods is the massive amount of
existing code which is doing something along the lines of:

if (System.getSecurityManager() != null) {
    doPrivileged(something);
} else {
    something.run();
}

It has nothing to do with what is in the JDK, which is why this item
was marked "optional" in the initial proposal.

> In this proposal, how privileges are established or propagated is
> implementation-specific. But how could applications or libraries depend
> on the APIs and still have some confidence that the code is behaving
> consistently and securely?

It is already an error to assume that code is behaving consistently
and securely on the sole basis of the presence of a SecurityManager,
and this would not change; the major difference is that the API would
be able to explicitly document this fact. The value that the user
gains from using a SecurityManager versus not using one would be that
JDK operations would be authorization checked.

> Today, the cost of buying into the SM model is high for libraries and
> applications. Not many third party libraries support the SM and have
> modified their code to perform permission checks and call doPrivileged
> in the right places. If there were pluggable SMs each behaving
> differently, there would likely be less incentive.

The point of retaining these APIs isn't necessarily to increase usage;
it is to provide some continuity for things which already expect some
level of authorization from the JDK. We think that it is the case that
this would add some value for our customers and users which offsets
the value lost by the removal of SM. The question is, is the value
enough to make our efforts to make this happen worthwhile? This is not
only a question of the cost of developing the JEP and implementation
effort, but also a question of how difficult it will be to gain enough
acceptance of the idea in the upstream community that the change could
potentially be integrated.

> Although it sounds beneficial to be able to delegate the SM
> implementation to a 3rd-party, in reality, I think very few people would
> take the time to implement it securely, and instead would mostly
> leverage its power to do things that aren't at all security related.

The fact that it has the word "security" in the name is really just a
historical curiosity, really. The APIs would be (and presently are)
security-related but were *never* adequate for the purposes for which
they were documented, i.e. sandboxing. We don't want it for
sandboxing, but for having a point at which we can authorize some of
these internal JDK operations in the same way we can authorize
higher-level operations.

Any suggestion of actual security by an implementation should
specifically be disclaimed in the API documentation. In fact that
should already be the case today, IMO. This is completely up to the
implementation, as would be any other guarantees, just as with any
other API.

I hope this clarifies things. Like I said, "no" is an acceptable
answer for us but I would be remiss if I didn't ensure that the "no"
was based on an accurate understanding of what we are proposing, so
hopefully this helps.
-- 
- DML • he/him