Re: A possible JEP to replace SecurityManager after JEP 411
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. With a policy tool that generates policy files, it allows the developer to turn off all features that are not required, which improves security. 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. -- Regards, Peter On 5/04/2022 11:52 pm, David Lloyd wrote: Here at Red Hat there have been serious discussions about the impacts of security manager removal on our users, and whether there is an actual value impact, and if so, whether it can be mitigated or reversed somehow. We are interested in exploring whether we can come up with a way in which vendors and projects that wish to continue using SecurityManager (or something like it) would be able to do so, while still removing the majority of the ongoing maintenance burden from the OpenJDK project. Before we make a decision on whether or not we think there is sufficient justification for working up a formal JEP, we have decided that the best first step would be to socialize the idea in a more general form so that we can know whether the upstream OpenJDK team would even be amenable *at all* to the solution (or something like it), particularly in light of the observation that previous threads about retaining SecurityManager in any form have been looked upon in a fairly negative light. The primary idea behind this proposal is that, while all of the points in JEP 411 relating to the lack of what most experts might refer to as "actual security" are certainly true, the SecurityManager mechanism itself does nevertheless have some inherent value. The challenge, then, is to strike a balance between the value provided by retaining some semblance of the mechanism versus the costs inherent in retaining it; we would want as much of the former as possible, for as little of the latter as possible. So, here's the idea. It is assumed (for the sake of common understanding) that as things stand, all of the classes and members marked as "deprecated for removal" as a part of JEP 411 are intended to be completely removed without replacement at the end of the term of deprecation. The proposals here are based on this assumption. The center of this proposal is that, at the end of the term of deprecation, all of the deprecated classes, members, and behavior are still removed (including, and especially, AccessController and Policy and related classes) /except/ as mentioned here: * Rather than completely removing SecurityManager, * The SecurityManager class becomes abstract and non-deprecated, with all of its methods being removed, except as follows * SecurityManager.getSecurityContext() becomes abstract (this is the one that returns Object, *not* the stack walking one) * SecurityManager.checkPermission() (both of them) become abstract * Rather than removing the SecurityManager-related methods from System, * System.getSecurityManager() is retained and de-deprecated * [Optional] System.setSecurityManager() is retained and de-deprecated (we would want to explore whether it is feasible to replace this (and the system property lookup mechanism) using ServiceLoader, if bootstrap allows it) * [Optional] Rather than /immediately/ removing all of AccessController, * Retain its deprecation-for-removal status * Retain only doPrivileged(PrivilegedAction) and doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no JVM semantics other than being present on the call stack like any method) since they are pervasively used, to allow frameworks time to transition to (for example) a third-party alternative. The burden of permission verification would lie completely with the security manager implementation. The JDK would not have a 'SecurityManager' implementation of any kind, outside of the internal test suite. The other part of this proposal can come in one of two possible flavors. ### Option 1: Authorization interfaces Each point in the JDK where there presently is a permission check is classified into an authorization category of related operations. An interface is introduced for each category which contains the methods encapsulating the relevant check, in a package that is deemed most appropriate for that particular grouping. For example, there might be a 'SocketAuthorization'
Re: RFR: 8284291: sun/security/krb5/auto/Renew.java fails intermittently on Windows 11
On Tue, 5 Apr 2022 08:23:39 GMT, Andrey Turbanov wrote: >> `Thread.sleep()` seems not very precise on some systems. Update this test to >> check the current time continously. > > 50 repeats. No failures. Thank you! @turbanoff Thanks for the code review. At the same time, I'm still curious why this could happen on your machine. If after `Thread.sleep(7000)` but the difference of `System.currentTimeMillis()` is less than 5000, then there must be a serious bug in either of the methods. How about the difference between `System.nanoTime()`? - PR: https://git.openjdk.java.net/jdk/pull/8098
RFR: 8209038: Clarify the javadoc of Cipher.getParameters()
Anyone can help review this javadoc update? The main change is the wording for
the method javadoc of Cipher.getParameters()/CipherSpi.engineGetParameters().
The original wording is somewhat restrictive and request is to broaden this to
accommodate more scenarios such as when null can be returned.
The rest are minor things like add {@code } to class name and null, and remove
redundant ".".
Will file CSR after the review is close to being wrapped up.
Thanks~
-
Commit messages:
- 8209038: Clarify the javadoc of Cipher.getParameters()
Changes: https://git.openjdk.java.net/jdk/pull/8117/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8117=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8209038
Stats: 254 lines in 2 files changed: 2 ins; 5 del; 247 mod
Patch: https://git.openjdk.java.net/jdk/pull/8117.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/8117/head:pull/8117
PR: https://git.openjdk.java.net/jdk/pull/8117
Re: RFR: 8284368: Remove finalizer method in jdk.crypto.cryptoki
On Tue, 5 Apr 2022 19:55:55 GMT, Xue-Lei Andrew Fan wrote: > Please review the update to remove finalizer method in the > jdk.crypto.cryptoki module. It is one of the efforts to clean up the use of > finalizer method in JDK. Looks good. Thanks! - Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8112
Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
BTW, since this is Windows specific anyway and since we have also a combining virtual Keystore, why not allow a new naming scheme which allows to access any of the Keystores? like “Windows-ROOT/ADdressbook”? Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Mat Carter Gesendet: Dienstag, April 5, 2022 5:22 PM An: Wei-Jun Wang Cc: security-dev@openjdk.java.net Betreff: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Hi Weijun Thank you for the feedback, I'd like to address point 2 first as I think this might also address point 1 >> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't >> want new entries suddenly appear >> there and automatically chosen by a key manager. >> >> It looks OK to enhance Windows-ROOT to cover more root CA certs in your >> organization but including >> new entries in Windows-MY is a little dangerous. It's OK to introduce a new >> store type for MY in LOCAL_MACHINE. I deliberately kept implementation details out of the initial email to focus on the security aspects, but this point makes an assumption that the results of using "Windows-MY" or "Windows-ROOT" would change with this new functionality; this is not what we're proposing. Specifically we're proposing adding two new strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE" such that developers can now access the key stores in the local machine. To be clear, the implementation would make no attempt to "merge" results when enumerating or to search both locations via a single key store instance; i.e. you can only create and instance for accessing either keystore but not both. I think this addresses point 1 also, but if not then I have a follow on question: >> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. >> The name implies that the certificate is >> trusted for any purpose. We don't want some certificates that were not meant >> to be trusted shown up. Our initial analysis leads us to believe that we'll not need to introduce new code paths to handle new certificates; i.e. the only code changes are how the key store is opened, subsequent calls to access certificates is handled by the existing code. Given the above assumption, your concerns laid out in point 1 and if your concern is not mitigated with our notes for point 2: is it the case that you expect new "types" of certificates to be accessible via local machine that weren't via current user and that some/all of these certs are "bad" (and would need new code paths to handle them)? While we are talking about implementation, there's another aspect we'd like to introduce/discuss: this is to allow developers to access the key stores with read only permissions, thus allowing enumeration and reading without requiring administrative permissions be granted to the application (thus increasing security) Thanks in advance Mat Sent from Outlook From: Wei-Jun Wang Sent: Friday, April 1, 2022 3:15 PM To: Mat Carter Cc: security-dev@openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Hi Mat, We have 2 main concerns: 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager. It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. And we have no plan to add other types like ADDRESSBOOK. Thanks, Weijun > On Mar 31, 2022, at 5:16 PM, Mat Carter wrote: > > Current support for KeyStores on Windows is limited to the current user > location [1] > > There has been previous request for local machine support [2] along with > discussion in the security-dev mailing list [3], further discussions have > occurred on stackoverflow in the past [4] and [5] > > Using JNI you can access local machine locations but then you are duplicating > much of the existing native functionality; this also adds the requirement > that developers need to know C/C++ and the Windows cryptography API. > > Given the above I propose that we add native support for local machine > KeyStore locations > > Users can currently access two physical key stores (in the current user > location): > > "Windows-MY": .Default > "Windows-ROOT": .Default.LocalMachine, .SmartCard > > Adding the local machine location opens up access to a further two physical > key stores … > > "Windows-MY": .Default > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard > > Please
Re: Proposal: Extend Windows KeyStore support to include access to the local machine location
Hi Weijun Thank you for the feedback, I'd like to address point 2 first as I think this might also address point 1 >> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't >> want new entries suddenly appear >> there and automatically chosen by a key manager. >> >> It looks OK to enhance Windows-ROOT to cover more root CA certs in your >>organization but including >> new entries in Windows-MY is a little dangerous. It's OK to introduce a new >>store type for MY in LOCAL_MACHINE. I deliberately kept implementation details out of the initial email to focus on the security aspects, but this point makes an assumption that the results of using "Windows-MY" or "Windows-ROOT" would change with this new functionality; this is not what we're proposing. Specifically we're proposing adding two new strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE" such that developers can now access the key stores in the local machine. To be clear, the implementation would make no attempt to "merge" results when enumerating or to search both locations via a single key store instance; i.e. you can only create and instance for accessing either keystore but not both. I think this addresses point 1 also, but if not then I have a follow on question: >> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. >> The name implies that the certificate is >> trusted for any purpose. We don't want some certificates that were not meant >> to be trusted shown up. Our initial analysis leads us to believe that we'll not need to introduce new code paths to handle new certificates; i.e. the only code changes are how the key store is opened, subsequent calls to access certificates is handled by the existing code. Given the above assumption, your concerns laid out in point 1 and if your concern is not mitigated with our notes for point 2: is it the case that you expect new "types" of certificates to be accessible via local machine that weren't via current user and that some/all of these certs are "bad" (and would need new code paths to handle them)? While we are talking about implementation, there's another aspect we'd like to introduce/discuss: this is to allow developers to access the key stores with read only permissions, thus allowing enumeration and reading without requiring administrative permissions be granted to the application (thus increasing security) Thanks in advance Mat Sent from Outlook From: Wei-Jun Wang Sent: Friday, April 1, 2022 3:15 PM To: Mat Carter Cc: security-dev@openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Hi Mat, We have 2 main concerns: 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager. It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. And we have no plan to add other types like ADDRESSBOOK. Thanks, Weijun > On Mar 31, 2022, at 5:16 PM, Mat Carter wrote: > > Current support for KeyStores on Windows is limited to the current user > location [1] > > There has been previous request for local machine support [2] along with > discussion in the security-dev mailing list [3], further discussions have > occurred on stackoverflow in the past [4] and [5] > > Using JNI you can access local machine locations but then you are duplicating > much of the existing native functionality; this also adds the requirement > that developers need to know C/C++ and the Windows cryptography API. > > Given the above I propose that we add native support for local machine > KeyStore locations > > Users can currently access two physical key stores (in the current user > location): > > "Windows-MY": .Default > "Windows-ROOT": .Default.LocalMachine, .SmartCard > > Adding the local machine location opens up access to a further two physical > key stores … > > "Windows-MY": .Default > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard > > Please let me know if there are any existing efforts to bring this > functionality to Java, or references to prior decisions on this subject > > Thanks in advance > Mat Carter > > [1] >
A possible JEP to replace SecurityManager after JEP 411
Here at Red Hat there have been serious discussions about the impacts
of security manager removal on our users, and whether there is an
actual value impact, and if so, whether it can be mitigated or
reversed somehow. We are interested in exploring whether we can come
up with a way in which vendors and projects that wish to continue
using SecurityManager (or something like it) would be able to do so,
while still removing the majority of the ongoing maintenance burden
from the OpenJDK project.
Before we make a decision on whether or not we think there is
sufficient justification for working up a formal JEP, we have decided
that the best first step would be to socialize the idea in a more
general form so that we can know whether the upstream OpenJDK team
would even be amenable *at all* to the solution (or something like
it), particularly in light of the observation that previous threads
about retaining SecurityManager in any form have been looked upon in a
fairly negative light.
The primary idea behind this proposal is that, while all of the points
in JEP 411 relating to the lack of what most experts might refer to as
"actual security" are certainly true, the SecurityManager mechanism
itself does nevertheless have some inherent value. The challenge,
then, is to strike a balance between the value provided by retaining
some semblance of the mechanism versus the costs inherent in retaining
it; we would want as much of the former as possible, for as little of
the latter as possible.
So, here's the idea. It is assumed (for the sake of common
understanding) that as things stand, all of the classes and members
marked as "deprecated for removal" as a part of JEP 411 are intended
to be completely removed without replacement at the end of the term of
deprecation. The proposals here are based on this assumption.
The center of this proposal is that, at the end of the term of
deprecation, all of the deprecated classes, members, and behavior are
still removed (including, and especially, AccessController and Policy
and related classes) /except/ as mentioned here:
* Rather than completely removing SecurityManager,
* The SecurityManager class becomes abstract and non-deprecated,
with all of its methods being removed, except as follows
* SecurityManager.getSecurityContext() becomes abstract (this is
the one that returns Object, *not* the stack walking one)
* SecurityManager.checkPermission() (both of them) become abstract
* Rather than removing the SecurityManager-related methods from System,
* System.getSecurityManager() is retained and de-deprecated
* [Optional] System.setSecurityManager() is retained and
de-deprecated (we would want to explore whether it is feasible to
replace this (and the system property lookup mechanism) using
ServiceLoader, if bootstrap allows it)
* [Optional] Rather than /immediately/ removing all of AccessController,
* Retain its deprecation-for-removal status
* Retain only doPrivileged(PrivilegedAction) and
doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no
JVM semantics other than being present on the call stack like any
method) since they are pervasively used, to allow frameworks time to
transition to (for example) a third-party alternative.
The burden of permission verification would lie completely with the
security manager implementation. The JDK would not have a
'SecurityManager' implementation of any kind, outside of the internal
test suite.
The other part of this proposal can come in one of two possible flavors.
### Option 1: Authorization interfaces
Each point in the JDK where there presently is a permission check is
classified into an authorization category of related operations. An
interface is introduced for each category which contains the methods
encapsulating the relevant check, in a package that is deemed most
appropriate for that particular grouping. For example, there might be
a 'SocketAuthorization' interface in the 'java.net' package, with
methods like 'checkConnect(SocketAddress from, SocketAddress to)' and
'checkAccept(SocketAddress addr)'.
At the point where a permission check previously would take place, a
check like this is performed instead:
if (System.getSecurityManager() instanceof SocketAuthorization sa) {
sa.checkAccept(addr);
}
Any public or protected method with such a check should include
@throws Javadoc explaining that a SecurityException may be thrown.
The Permission subclasses previously used specifically by these
operation sites *may* in this case be deprecated for removal
immediately or at some point in the future, if desired.
It is the sole responsibility of the SecurityManager implementer to
implement the various necessary interfaces, and any third-party
authorization interfaces that would also be relevant.
### Option 2: Retain permission system
Under this option, the existing authorization checks are mostly
retained, however, since the SecurityManager class only has a
