A possible JEP to replace SecurityManager after JEP 411

[David Lloyd]

Thanks for responding Peter, I've commented inline below.

On Tue, Apr 5, 2022 at 8:19 PM Peter Firmstone
<peter.firmstone at zeus.net.au> wrote:
>
> Thanks David,
>
> I'd certainly support such a proposal and encourage OpenJDK to consider
> exploring it.
>
> Perhaps also consider; no privileges should be granted unless a
> privileged call is made, this simplifies the the stack walk, such that
> it's only required when a privileged call is made.

I think this is a reasonable requirement for an implementation. If we
move forward with this however, the proposal would explicitly not
specify how privileges are established or propagated; that would be
implementation-defined.

> With a policy tool that generates policy files, it allows the developer
> to turn off all features that are not required, which improves security.

Policy is specifically excluded from the proposal and would be
implementation-defined. This should grant significantly more
flexibility to meet the authorization needs of the end user.

For example, one implementation could be designed to perform
authorization checks based on the call stack, like AccessController
does today. Another implementation might authorize based on an
authenticated user identity and not be concerned with the call stack
at all. Other implementations might do both.

> Something that bothered me about SocketPermission was that it didn't
> allow granting permission to subnets, or ranges of IP addresses.
>
> It always bothered me that data parsing isn't controlled with permissions.
>
> For data parsing the remote authenticated subject represents the source
> of the data, if the data source cannot be authenticated, then data
> cannot be parsed.   Of  course when parsing is done it needs to be
> validated, but authentication goes a long way to filtering out potential
> attack vectors.

By removing the bulk of the specification from the JDK, the
implementation is more free to define how permissions are granted and
checked (for example, by authorizing by CIDR ranges rather than by
single addresses). Both proposal options would allow for the
possibility of adding more authorization checks in the future in a
reasonably backwards compatible way, though I think in practice it is
unlikely (except maybe in the context of new features that might
benefit from such checks).

The reason that this is a "proposal to propose" rather than an actual
proposal is because we ourselves do not have a clear answer as to
whether the costs even of this simplified compromise solution are low
enough, compared to the expected value return, to justify the work
necessary to produce a formal proposal and prototype. If the upstream
consensus is "no, we're not likely to approve this", we're going to
consider having to plead our case when we decide whether we want to
devote that effort as an additional cost.

And we really do have to balance cost and benefit *to us* as well as
to the OpenJDK team. When suggesting new features it's always tempting
to try and "boil the ocean", especially when inspiration strikes and
one is tempted to incorporate dozens of new and interesting ideas. But
in this particular case, the real benefit comes from figuring out what
we can *remove* versus what must be kept: the more we can remove, the
simpler the change would be, and the more likely it will be that we
can justify the labor involved in making the change - and, I think,
the more likely that the proposal would be palatable to the upstream
OpenJDK maintainers.

As a final note, I don't think that any context-based authorization
based system would really suffice for handling tainted data,
unfortunately. For some languages, tainted data is handled at a
language level. We would not set out to solve that problem with this
proposal, though I think we would all agree that this is a real
problem and I think it's safe to speculate that Red Hat would likely
be in favor of any effort to tackle it.

-- 
- DML • he/him