<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Sean,</p>
<p>In order to keep our code up to date with Java, we need to
replace access control functionality. Current advise is that we
will need to instrument the Java API, once finalizers have been
removed.</p>
<p>The sticking point is about the retention of permission checks,
which haven't been deprecated by JEP411, OpenJDK does not wish to
maintain permission checks.<br>
</p>
<p>We currently use authentication and access control to prevent
parsing untrusted data, or loading untrusted code.</p>
<p>This task might be easier if each of the following only have one
location (or well documented locations) to instrument in the Java
language public API:</p>
<ol>
<li>Network access</li>
<li>File access</li>
<li>Property access</li>
<li>ClassLoader access / creation.</li>
<li>Keystores and credentials.<br>
</li>
</ol>
<p>We also need ways to prevent the jvm from being instrumented, by
an outside attacker.</p>
<p>Instead of worrying about permission checks and calls to
SecurityManager, OpenJDK devs just need to ensure they are using
these standard control points / hooks.<br>
</p>
<p>Regards,</p>
<p>Peter.<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/04/2022 5:19 am, Sean Mullan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com">Hi
David,
<br>
<br>
Thanks for the feedback and spending some time on this proposal.
Some specific comments below.
<br>
<br>
On 4/5/22 9:52 AM, David Lloyd wrote:
<br>
<blockquote type="cite">Here at Red Hat there have been serious
discussions about the impacts
<br>
of security manager removal on our users, and whether there is
an
<br>
actual value impact, and if so, whether it can be mitigated or
<br>
reversed somehow. We are interested in exploring whether we can
come
<br>
up with a way in which vendors and projects that wish to
continue
<br>
using SecurityManager (or something like it) would be able to do
so,
<br>
while still removing the majority of the ongoing maintenance
burden
<br>
from the OpenJDK project.
<br>
<br>
Before we make a decision on whether or not we think there is
<br>
sufficient justification for working up a formal JEP, we have
decided
<br>
that the best first step would be to socialize the idea in a
more
<br>
general form so that we can know whether the upstream OpenJDK
team
<br>
would even be amenable *at all* to the solution (or something
like
<br>
it), particularly in light of the observation that previous
threads
<br>
about retaining SecurityManager in any form have been looked
upon in a
<br>
fairly negative light.
<br>
<br>
The primary idea behind this proposal is that, while all of the
points
<br>
in JEP 411 relating to the lack of what most experts might refer
to as
<br>
"actual security" are certainly true, the SecurityManager
mechanism
<br>
itself does nevertheless have some inherent value. The
challenge,
<br>
then, is to strike a balance between the value provided by
retaining
<br>
some semblance of the mechanism versus the costs inherent in
retaining
<br>
it; we would want as much of the former as possible, for as
little of
<br>
the latter as possible.
<br>
</blockquote>
<br>
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). 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). Any missing checks would need to be
treated as security issues. 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.
<br>
<br>
The proposal also includes retaining calls to doPrivileged (but
later potentially replacing them with some other mechanism TBD).
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.
<br>
<br>
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.
<br>
<br>
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?
<br>
<br>
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.
<br>
<br>
Although it sounds beneficial to be able to delegate the SM
implementation to a 3rd-party, in reality, I think very few people
would
<br>
take the time to implement it securely, and instead would mostly
<br>
leverage its power to do things that aren't at all security
related. Sure, removing the default SM and Policy implementation
reduces the complexity a little, but there would still be a fairly
significant maintenance overhead and an additional drawback that
it would make it more difficult for applications and libraries to
depend on any type of consistent behavior.
<br>
<br>
--Sean
<br>
<br>
<br>
<blockquote type="cite">So, here's the idea. It is assumed (for
the sake of common
<br>
understanding) that as things stand, all of the classes and
members
<br>
marked as "deprecated for removal" as a part of JEP 411 are
intended
<br>
to be completely removed without replacement at the end of the
term of
<br>
deprecation. The proposals here are based on this assumption.
<br>
<br>
The center of this proposal is that, at the end of the term of
<br>
deprecation, all of the deprecated classes, members, and
behavior are
<br>
still removed (including, and especially, AccessController and
Policy
<br>
and related classes) /except/ as mentioned here:
<br>
<br>
* Rather than completely removing SecurityManager,
<br>
* The SecurityManager class becomes abstract and
non-deprecated,
<br>
with all of its methods being removed, except as follows
<br>
* SecurityManager.getSecurityContext() becomes abstract
(this is
<br>
the one that returns Object, *not* the stack walking one)
<br>
* SecurityManager.checkPermission() (both of them) become
abstract
<br>
* Rather than removing the SecurityManager-related methods
from System,
<br>
* System.getSecurityManager() is retained and
de-deprecated
<br>
* [Optional] System.setSecurityManager() is retained and
<br>
de-deprecated (we would want to explore whether it is feasible
to
<br>
replace this (and the system property lookup mechanism) using
<br>
ServiceLoader, if bootstrap allows it)
<br>
* [Optional] Rather than /immediately/ removing all of
AccessController,
<br>
* Retain its deprecation-for-removal status
<br>
* Retain only doPrivileged(PrivilegedAction) and
<br>
doPrivileged(PrivilegedExceptionAction) as simple pass-throughs
(no
<br>
JVM semantics other than being present on the call stack like
any
<br>
method) since they are pervasively used, to allow frameworks
time to
<br>
transition to (for example) a third-party alternative.
<br>
<br>
The burden of permission verification would lie completely with
the
<br>
security manager implementation. The JDK would not have a
<br>
'SecurityManager' implementation of any kind, outside of the
internal
<br>
test suite.
<br>
<br>
The other part of this proposal can come in one of two possible
flavors.
<br>
<br>
### Option 1: Authorization interfaces
<br>
<br>
Each point in the JDK where there presently is a permission
check is
<br>
classified into an authorization category of related operations.
An
<br>
interface is introduced for each category which contains the
methods
<br>
encapsulating the relevant check, in a package that is deemed
most
<br>
appropriate for that particular grouping. For example, there
might be
<br>
a 'SocketAuthorization' interface in the 'java.net' package,
with
<br>
methods like 'checkConnect(SocketAddress from, SocketAddress
to)' and
<br>
'checkAccept(SocketAddress addr)'.
<br>
<br>
At the point where a permission check previously would take
place, a
<br>
check like this is performed instead:
<br>
<br>
if (System.getSecurityManager() instanceof
SocketAuthorization sa) {
<br>
sa.checkAccept(addr);
<br>
}
<br>
<br>
Any public or protected method with such a check should include
<br>
@throws Javadoc explaining that a SecurityException may be
thrown.
<br>
<br>
The Permission subclasses previously used specifically by these
<br>
operation sites *may* in this case be deprecated for removal
<br>
immediately or at some point in the future, if desired.
<br>
<br>
It is the sole responsibility of the SecurityManager implementer
to
<br>
implement the various necessary interfaces, and any third-party
<br>
authorization interfaces that would also be relevant.
<br>
<br>
### Option 2: Retain permission system
<br>
<br>
Under this option, the existing authorization checks are mostly
<br>
retained, however, since the SecurityManager class only has a
general
<br>
'checkPermission()' method, the logic previously found in the
<br>
'SecurityManager' class which expands specific check calls into
<br>
general 'checkPermission()' calls (for example, calls to
<br>
'checkConnect' for sockets) would necessarily become the
<br>
responsibility of the site of the permission check. Some work
would
<br>
be undertaken
<br>
to refactor this code accordingly.
<br>
<br>
With this solution, the corresponding Permission subclasses
would be
<br>
retained indefinitely.
<br>
<br>
In either case it is the responsibility of the implementer of
<br>
SecurityManager to utilize these checks appropriately for
<br>
authorization decisions, based on whatever factors are deemed
<br>
appropriate, which may include contextual information such as a
<br>
currently-authenticated identity or the call stack, or (for
example) a
<br>
context object utilizing the ScopeLocal mechanism.
<br>
<br>
### Other changes
<br>
<br>
It would be worth exploring whether the SecurityManager
installation
<br>
could be refitted to use the ServiceLoader mechanism (for
example at
<br>
first call to getSecurityManager()) based on the class loader of
the
<br>
application class or module path. This would allow the
<br>
'System.setSecurityManager' method, and support for the
corresponding
<br>
system property, to be removed at the end of the term of
deprecation.
<br>
<br>
Testing
<br>
<br>
Neither solution would ease the burden of testing from the JDK
quite
<br>
as much as complete removal, of course. The necessary testing
for the
<br>
individual checks should be limited to ensuring that the
permission
<br>
check calls are happening with correct arguments and that any
thrown
<br>
SecurityException is propagated. The policy for testing
<br>
SecurityManager installation would depend on whether, and to
what
<br>
extent, the more recent changes restricting the installation of
the
<br>
security manager are reversed. Other testing issues may arise
as
<br>
well.
<br>
<br>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>