Re: RFR: 8271566: DSA signature length value is not accurate in P11Signature
On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao wrote:
> As described in JDK-8271566 [1], this patch proposal is intended to fix a
> problem that arises when using DSA keys that have a 256-bits (or larger) G
> parameter for signatures (either signing or verifying). There were some
> incorrect assumptions and hard-coded length values in the code before. Please
> note that, for example, the tuple (2048, 256) for DSA is valid according to
> FIPS PUB 186-4.
>
> Beyond the specific issues in signatures, I decided to provide a broader
> solution and enable key parameter retrieval for other key types (EC, DH) when
> possible. This is, when the key is not sensitive. One thing that I should
> note here is that token keys (those that have the CKA_TOKEN attribute equal
> to 'true') are considered sensitive in this regard, at least by the NSS
> Software Token implementation. I don't have access to other vendor
> implementations but if there is any concern, we can adjust the constraint to
> NSS-only. However, I'm not sure which use-case would require to get private
> keys out of a real token, weakening its security. I'd be more conservative
> here and not query the values if not sure that it will succeed.
>
> No regressions found in jdk/sun/security/pkcs11. A new test added:
> LargerDSAKey.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java
line 123:
> 121:
> 122: // signature length expected or 0 for unknown
> 123: private int signatureLength;
nit: use a shorter name, e.g. sigLen, so to fit in one line.
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java
line 817:
> 815: }
> 816:
> 817: private byte[] asn1ToDSA(byte[] sig) throws SignatureException {
Have you considered keeping this as a static method but add one more int
argument, i.e. signature length? It seems that the method asn1ToECDSA() can be
made static too.
-
PR: https://git.openjdk.java.net/jdk/pull/4961
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v7]
On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures >> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES >> and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with five additional > commits since the last revision: > > - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm > - Updates, comment and variable cleanup > - merge rest > - merge > - fixes and code comments The latest changes I just pushed into the repo should address the remaining Java issues. - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8271566: DSA signature length value is not accurate in P11Signature
On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao wrote:
> As described in JDK-8271566 [1], this patch proposal is intended to fix a
> problem that arises when using DSA keys that have a 256-bits (or larger) G
> parameter for signatures (either signing or verifying). There were some
> incorrect assumptions and hard-coded length values in the code before. Please
> note that, for example, the tuple (2048, 256) for DSA is valid according to
> FIPS PUB 186-4.
>
> Beyond the specific issues in signatures, I decided to provide a broader
> solution and enable key parameter retrieval for other key types (EC, DH) when
> possible. This is, when the key is not sensitive. One thing that I should
> note here is that token keys (those that have the CKA_TOKEN attribute equal
> to 'true') are considered sensitive in this regard, at least by the NSS
> Software Token implementation. I don't have access to other vendor
> implementations but if there is any concern, we can adjust the constraint to
> NSS-only. However, I'm not sure which use-case would require to get private
> keys out of a real token, weakening its security. I'd be more conservative
> here and not query the values if not sure that it will succeed.
>
> No regressions found in jdk/sun/security/pkcs11. A new test added:
> LargerDSAKey.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566
test/jdk/sun/security/pkcs11/Signature/LargeDSAKey.java line 52:
> 50: "Known text known text known text";
> 51:
> 52: public void main(Provider p) throws Exception {
nit: add @Override
-
PR: https://git.openjdk.java.net/jdk/pull/4961
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v7]
> I would like to submit AES-GCM optimization for x86_64 architectures > supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES > and GHASH operations. > Performance gain of ~1.5x - 2x for message sizes 8k and above. Smita Kamath has updated the pull request incrementally with five additional commits since the last revision: - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm - Updates, comment and variable cleanup - merge rest - merge - fixes and code comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/4019/files - new: https://git.openjdk.java.net/jdk/pull/4019/files/0f834eed..69145008 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4019=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4019=05-06 Stats: 219 lines in 1 file changed: 83 ins; 60 del; 76 mod Patch: https://git.openjdk.java.net/jdk/pull/4019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019 PR: https://git.openjdk.java.net/jdk/pull/4019
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
Maybe we need some criteria, that defines what's not easily instrumented? On 4/08/2021 10:19 am, Peter Firmstone wrote: Excellent, Ron, that's exactly what I'm after. I need to be able to implement an authorization layer on top of the JDK, but reach down into the JDK to use authorization to control access. Can we find out how many such checks that OpenJDK is prepared to support, then we will pick the most important? Don't worry about ClassLoader, I can instrument that (thank you Erik), and maybe I can instrument Properties, and System.exit. So basically things we can't easily instrument with agents, that everybody is most likely to want. * Network access * File System access * User Credentials Maybe we should have a mailing list dedicated to this where we can discuss and potentially collaborate? Regards, Peter. On 3/08/2021 10:15 pm, Ron Pressler wrote: On 3 Aug 2021, at 12:50, Peter Firmstone wrote: Can you think of any workable alternative compromises? If you mean a compromise between no access checks in the JDK and all access checks in the JDK, then yes, which is possibly some callbacks for a small subset of operations that perform access checks today, say, System.exit and opening a file or socket. I am not saying this is what should be done, but that the effort involved is such that I can conceivably see those whose responsibility this would be agreeing to consider it, as the value in such a mechanism might end up being worthy of that amount of effort. But I’m guessing that the more such hooks are requested, the less likely it is that the cost remains acceptable. — Ron -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd.
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
Excellent, Ron, that's exactly what I'm after. I need to be able to implement an authorization layer on top of the JDK, but reach down into the JDK to use authorization to control access. Can we find out how many such checks that OpenJDK is prepared to support, then we will pick the most important? Don't worry about ClassLoader, I can instrument that (thank you Erik), and maybe I can instrument Properties, and System.exit. So basically things we can't easily instrument with agents, that everybody is most likely to want. * Network access * File System access * User Credentials Maybe we should have a mailing list dedicated to this where we can discuss and potentially collaborate? Regards, Peter. On 3/08/2021 10:15 pm, Ron Pressler wrote: On 3 Aug 2021, at 12:50, Peter Firmstone wrote: Can you think of any workable alternative compromises? If you mean a compromise between no access checks in the JDK and all access checks in the JDK, then yes, which is possibly some callbacks for a small subset of operations that perform access checks today, say, System.exit and opening a file or socket. I am not saying this is what should be done, but that the effort involved is such that I can conceivably see those whose responsibility this would be agreeing to consider it, as the value in such a mechanism might end up being worthy of that amount of effort. But I’m guessing that the more such hooks are requested, the less likely it is that the cost remains acceptable. — Ron
Re: JEP 411, removal of finalizers, a path forward.
On 4/08/2021 2:40 am, Sean Mullan wrote: On 8/2/21 8:28 PM, Peter Firmstone wrote: In JGDMS without SM, at least the following must be addressed to maintain security: 1. TLS and Kerberos connections cannot be established. (My software is littered with doPrivileged calls that preserve the Subject, we don't have anon TLS connections, we require client certificates). As mentioned several times, this use case will be preserved and is already covered in JEP 411: https://openjdk.java.net/jeps/411#subject-doas Yes, that's true, a secondary consideration is the amount of work that will be required to support different versions of Java, no doubt reflection will be helpful, to check for the existence of the new methods. Last time I checked, I have around 1,000 locations in the code that will require changes. My motivation for mentioning it was to highlight the benefit of reusing existing methods, which currently provide this functionality. 2. All remote connections are authorized to load classes. Not sure why you can't do something with a custom ClassLoader that only loads classes for authorized users. Interesting, what do you have in mind? We currently do have a hierarchy of custom ClassLoaders, however its concern is class resolution at client endpoints (Warning this isn't simple and may be confusing if you're not familiar with Jini and I may not be able to explain it sufficiently for it to be simply understood). We have solved some extremely difficult software design problems that Sun Microsystems left unresolved with Jini. https://dl.acm.org/doi/epdf/10./1698139 Our software architecture is designed for separation of concerns. Grafting authorization onto ClassLoader's doesn't sound like a good design decision, however I'm listening. Our current ClassLoader inheritance hierarchy: SecureClassLoader -> URLClassLoader -> RFC3986URLClassLoader -> PreferredClassLoader The reason I highlight SecureClassLoader is, we override SecureClassLoader methods to replace CodeSource, with a CodeSource that uses RFC3986 and RFC5952 normalization for identity in SecureClassLoader, to avoid DNS calls and to normalize IPv6 addresses where DNS isn't used and endpoints contact each other directly and their identity needs to be defined by their normalized address. However, PreferredClassLoader, modifies class resolution, allowing the authenticated service to resolve classes that it prefers, from it's own CodeSource, before they are loaded from the parent ClassLoader, that it lists as preferred, allowing the service to have a weak form of Isolation (we didn't design this, inherited from Sun). In our JERI (Jini Extensible Remote Invocation) Endpoints, ClassLoader's are assigned at both Client and Server Endpoint's, for class resolution (we designed this), and at the client endpoint, each ClassLoader is unique to the identity of the Service, the authenticated Subject of the Service, is part of the Service identity. Only the Service can deserialize (not Java serialization) into this ClassLoader, but only after authenticating. Unlike Java RMI, we don't annotate codebases in the stream (a mistake that duplicates the ClassLoader class resolution mechanism), instead we assign ClassLoaders for class resolution at both endpoints when the streams are created, the ClassLoader is provisioned with the correct codebase for the service, after authentication. A user is assigned GrantPermission( Insert Java permission here) in policy files, users can dynamically grant permissions to a Service, after it has authenticated, the service, advises the client of Permissions it needs, the permissions granted are the intersection of the sets of what the client is willing and authorized to grant, and the permissions requested by the Service. This might highlight why the simplest option at this time is to re-implement an authorization layer. The resulting capability and power of these features are not widely understood or known. Think of a service, that can be advertised on any IPv6 network, anywhere in the world, and be discovered by a user on an IPv6 anywhere else in the world, without an intermediary. Over secure sockets. Provided the user and the service have common trust certificates, they could be from the same company, or part of a club or organization. For example multiple parties can participate in a transaction globally. 3. All remote connections are authorized to perform deserialization. Depending on serialization long-term seems somewhat dubious. Agreed, in many of my previous emails I've added brackets after serialization that state (not Java serialization), perhaps I should just start calling it not Java serialization, this was written prior to the introduction of serialization filters, to address the shortcomings of Java Serialization, it's a subset of Java serialization re-implemented to use constructors and
Re: RFR: 8271566: DSA signature length value is not accurate in P11Signature
On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao wrote:
> As described in JDK-8271566 [1], this patch proposal is intended to fix a
> problem that arises when using DSA keys that have a 256-bits (or larger) G
> parameter for signatures (either signing or verifying). There were some
> incorrect assumptions and hard-coded length values in the code before. Please
> note that, for example, the tuple (2048, 256) for DSA is valid according to
> FIPS PUB 186-4.
>
> Beyond the specific issues in signatures, I decided to provide a broader
> solution and enable key parameter retrieval for other key types (EC, DH) when
> possible. This is, when the key is not sensitive. One thing that I should
> note here is that token keys (those that have the CKA_TOKEN attribute equal
> to 'true') are considered sensitive in this regard, at least by the NSS
> Software Token implementation. I don't have access to other vendor
> implementations but if there is any concern, we can adjust the constraint to
> NSS-only. However, I'm not sure which use-case would require to get private
> keys out of a real token, weakening its security. I'd be more conservative
> here and not query the values if not sure that it will succeed.
>
> No regressions found in jdk/sun/security/pkcs11. A new test added:
> LargerDSAKey.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 386:
> 384: (attributes[2].getBoolean() == false)) {
> 385: keySensitive = true;
> 386: }
nit: this block and line 377 can simply be:
`boolean keySensitive = (attributes[0].getBoolean() ||
attributes[1].getBoolean() || (!attributes[2].getBoolean()));`
-
PR: https://git.openjdk.java.net/jdk/pull/4961
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
> On 3 Aug 2021, at 12:50, Peter Firmstone wrote: > > Can you think of any workable alternative compromises? If you mean a compromise between no access checks in the JDK and all access checks in the JDK, then yes, which is possibly some callbacks for a small subset of operations that perform access checks today, say, System.exit and opening a file or socket. I am not saying this is what should be done, but that the effort involved is such that I can conceivably see those whose responsibility this would be agreeing to consider it, as the value in such a mechanism might end up being worthy of that amount of effort. But I’m guessing that the more such hooks are requested, the less likely it is that the cost remains acceptable. — Ron
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
> On 3 Aug 2021, at 06:48, Peter Firmstone wrote: > > > We can still use these without an SM, Policy or Permissions for authorization > decisions, as mentioned previously I'd replace the inherited thread context > with an unprivileged context, and also allow the stack walk to be disabled > for people only using Subject. > I think what you mean is that you can envision using the same API points for a different, but reasonably similar role to the one they have. But that would mean changing the behaviour of existing classes, possibly making some final classes non-final, in non-trivial ways. > > Just performed a search for java.security.AccessController on GitHub, got > 1,398,418 results for Java: > The plan is to degrade these into no-ops until such time as most of those usages disappear, not to imbue those lines of code with new meaning. The actual removal of the API elements might be a long way off, but, becoming no-ops before then, the JDK and libraries will be free to remove those usages.
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
> On 3 Aug 2021, at 09:39, Peter Firmstone wrote: > > > > Can you elaborate? A Runnable, similar to registering a shutdown hook? > Maybe, but there have been no specifics beyond saying that something like that, and which requires that level of effort, might, after the dust settles and no one is rushing to decisions, possibly be something that we could contemplate thinking about considering as possibly not being obviously completely unreasonable, and might, perhaps, be worthy of another look.
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
What you are proposing is: 1. Add an SPI for deep permission checks in the JDK. 2. Do so by changing the behaviour of existing classes in a non-trivial way. 3. Keep access checks in the JDK. I do not speak for those who work on the security mechanisms, but I believe that none one of these, even in isolation, would be reasonable. For one, even without the principle against changing the behaviour of existing classes in drastic and non-trivial ways, without the use of doPrivileged in the JDK, AccessController would make a bad API. For another, the cost of SM isn’t in the lines of code that make up the AccessController implementation but in the fact that the JDK does access checks and privileged operations in the first place, as those impose a tax on everything, and also take resources away from what we believe is more robust and effective security. The starting point isn’t removing the policy file implementation, but removing all access checks and privileged operations from the JDK, and everything else follows from there (it will take a long time until API elements are actually removed, anyway). Even if someone might choose to contemplate adding callbacks to one or two I/O operations, it is not the intent for the JDK to participate in a general access checking mechanism deep in its guts in addition to strong encapsulation; quite the opposite. — Ron > On 3 Aug 2021, at 10:44, Peter Firmstone wrote: > > Thanks Ron, reply inline. > > On 3/08/2021 6:48 pm, Ron Pressler wrote: >> >>> On 3 Aug 2021, at 06:48, Peter Firmstone >>> wrote: >>> >>> >>> We can still use these without an SM, Policy or Permissions for >>> authorization decisions, as mentioned previously I'd replace the inherited >>> thread context with an unprivileged context, and also allow the stack walk >>> to be disabled for people only using Subject. >>> >>> >> I think what you mean is that you can envision using the same API points for >> a different, but reasonably similar >> role to the one they have. But that would mean changing the behaviour of >> existing classes, possibly making some >> final classes non-final, in non-trivial ways. >> > I'd limit changes to: > > • Make the stack walk optional (via command line argument to disable > it). > • Remove Thread's inherited context, replace it with an unprivileged > context. > This would allow us to use the API for virtual threads, eg to obtain Subject > credentials to authenticate TLS connections. > > It also means that for someone implementing guard checks, that these only > need check the thread stack back to the last doPrivileged call, or the start > of the thread, in the latter case it will have no privileges. It fixes the > viral permission check problem, usually doPrivileged calls are short and > sweet. > > It may require the addition of doPrivileged calls where they're currently > missing (and should have been used), where they've been responsible for viral > permission checks. > >> >>> Just performed a search for java.security.AccessController on GitHub, got >>> 1,398,418 results for Java: >>> >>> >> The plan is to degrade these into no-ops until such time as most of those >> usages disappear, not to imbue >> those lines of code with new meaning. The actual removal of the API elements >> might be a long way off, >> but, becoming no-ops before then, the JDK and libraries will be free to >> remove those usages. >> > No new meanings, the same as they have now is sufficient, just we leave the > granularity of the checks to the developers of guards and provide a means by > which guards can be registered for common check points that developers > request (perhaps via a poll), rather than all existing permission check > points. Keeping in mind that we are not trying to isolate code, but perform > authorization access checks, as well as provide credentials for > authentication. > > For example, if someone is only concerned with stopping the JVM from exiting, > then they only implement a guard for that particular hook, the actual code > that needs to call System::exit, then calls a doPrivileged method before > doing so. The guard need only check the domain on the stack is the one it > expects, which could be based on Principal, CodeSource, Module or ClassLoader > etc, they may also chose to implement something more complex. > > Someone else may only be concerned with network connections, so they only > implement and register a guard for that. > > So basically we don't dictate how to implement guards or policy, we just > leave enough in place, to ensure that a minimalist authorization access > control api is common among all implementations on all Java versions. > > It is suitable, for Subject's only or code and Subject's. > > The doPrivileged call simply indicates the code is requesting to do something > that might be privileged, or needs to provide credentials for authentication, > as it does now, but
Re: Incorrect encoding of PKCS12 bag attributes
Max,
indeed! I was looking too low-level while analyzing how stuff works.
friendlyName is handled as expected. Thank you for the clarification and
apoligies for the noise.
Regards,
Michael
Am 2021-08-01 um 03:54 schrieb Wei-Jun Wang:
Hi Michael,
I’m not sure what exact problem you ran into, but looking at the implementation
of PKCS12KeyStore at [1] the friendly name is hardcoded to be encoded in
BMPString:
bagAttr1.putOID(PKCS9FriendlyName_OID);
DerOutputStream bagAttrContent1 = new DerOutputStream();
DerOutputStream bagAttrValue1 = new DerOutputStream();
bagAttrContent1.putBMPString(alias);
On line 2523 of the same file, it’s also always decoded as BMPString:
if (attrId.equals(PKCS9FriendlyName_OID)) {
alias = valSet[0].getBMPString();
I did try to create a PKCS12 keystore with `-alias acéü`, and the result is
indeed BMPString:
: 1E 08 00 61 00 63 00 E9 00 FC...a.c
—Max
[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F6765f902505fbdd02f25b599f942437cd805cad1%2Fsrc%2Fjava.base%2Fshare%2Fclasses%2Fsun%2Fsecurity%2Fpkcs12%2FPKCS12KeyStore.java%23L1646data=04%7C01%7C9d76b566-97f1-4355-9dbf-6dcc0e8868d3%40ad011.siemens.com%7C1747436d78464899aa7d08d9548f4e5b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637633796747677305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JZcwDAqmzCbNmMSAaZiagdUpMNCCZxH59bs4a4avERo%3Dreserved=0
On Jul 30, 2021, at 11:26 AM, Osipov, Michael (LDA IT PLM)
wrote:
Am 2021-07-29 um 16:05 schrieb Sean Mullan:
Are you calling the PKCS12Attribute(String, String) constructor from your code?
That API currently specifies that String values are encoded as UTF-8, so we
could not change the behavior without a specification change. Can you use the
PKCS12Attribute(byte[]) constructor instead which takes a DER-encoded value?
Hi Sean,
I don't use this API. I interact with
KeyStore javaTrustStore = KeyStore.getInstance("PKCS12");
javaTrustStore.load(null, null);
for (Rdn rdn : ldapName.getRdns()) {
if (rdn.getType().equalsIgnoreCase("CN"))
alias = (String) rdn.getValue();
}
javaTrustStore .setCertificateEntry(alias, cert);
only. So I am using a high level API. But even if I'd use this API and pass the
UCS-2 encoded byte array of that cert
CN=NetLock Arany (Class Gold) Főtanúsítvány,OU=Tanúsítványkiadók (Certification
Services),O=NetLock Kft.,L=Budapest,C=HU
The ASN.1 tag would still be incorrect for friendlyName (1.2.840.113549.1.9.20)
because it would OctetString and not BMPString.
It seems to be that the API, or ObjectIdentifier and KnownOIDs classes miss to
carry the ASN.1 tag for the actual value. Don't they?
Michael
PS: This CA
CN=E-Tugra Certification Authority,OU=E-Tugra Sertifikasyon Merkezi,O=E-Tuğra
EBG Bilişim Teknolojileri ve Hizmetleri A.Ş.,L=Ankara,C=TR
was smart enough to stick with US-ASCII only in the CN, but still single-byte
!= two-byte UCS-2
On 6/14/21 3:21 PM, Osipov, Michael (LDA IT PLM) wrote:
Folks,
can someone confirm the following bug or tell me I am too stupid to read
the RFCs:
I have recently created a PKCS12-based trust store and had one CA from
Hungary with non-ASCII chars in the subject's CN RDN.
RFC 7292 for friendlyName refers to RFC 2985, section 5.5.1:
friendlyName ATTRIBUTE ::= {
WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
EQUALITY MATCHING RULE caseIgnoreMatch
SINGLE VALUE TRUE
ID pkcs-9-at-friendlyName
}
So a BMPString -- which is UCS-2 encoding. Looking at [1] shows that
Java ignores the RFC and always creates an UTF8String regardless of the
attribute OID, thus breaking the semantics of friendlyName.
Who's wrong here?
For some strange reason OpenSSL does it in a similar fashion:
In pkcs12.h.in:
> # define PKCS12_add_friendlyname PKCS12_add_friendlyname_utf8
where the function contains:
if (X509at_add1_attr_by_NID(>attrib, NID_friendlyName,
MBSTRING_UTF8, (unsigned char *)name,
namelen) != NULL)
[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F739769c8fc4b496f08a92225a12d07414537b6c0%2Fsrc%2Fjava.base%2Fshare%2Fclasses%2Fjava%2Fsecurity%2FPKCS12Attribute.java%23L230-L245data=04%7C01%7C9d76b566-97f1-4355-9dbf-6dcc0e8868d3%40ad011.siemens.com%7C1747436d78464899aa7d08d9548f4e5b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637633796747677305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=90U%2BMTFtF5WrEIYQGSK0AR3cc92J%2Bd1QZtHAmfvyii8%3Dreserved=0
Regards,
Michael
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
> On 3 Aug 2021, at 02:30, Peter Firmstone wrote: > > > I am still hopeful that OpenJDK might create some hooks for us and keep the > AccessController, AccessControlContext and Subject.doAs methods to make > supporting all Java versions easier. When I mentioned “hooks” I was referring to something along the lines of a callback when a file is accessed. > > Just curious, when using Agents, what are the recommendations for line > numbers in code, for exceptions etc, how are these affected when > instrumenting? When you transform a class, you basically replace its content with new content, so the short answer is that what happens to line numbers is whatever you want. If you’re using ASM for your transformation and ignore line numbers, which ASM represents as a kind of no-op instructions, then what would usually happen is that if original instruction X is mapped to line N and when transforming the stream you replace X with YXZ, then all of YXZ will remain mapped to line N.
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
Our path to making Java more secure is, indeed, similar to what you’re proposing. The general direction is that the application, rather than the libraries, will have the final say on security-sensitive capabilities. Just as strong encapsulation is now on by default, other things, such as native code, some dynamic Agent capabilities, and perhaps others, will likely require explicit permission by the application on the command line. I don’t know the details about management, but I believe that remote management requires explicit permission already. I am not aware, however, of plans to restrict class loading. The idea is that code is trusted to do what it says it does, and what’s restricted is the ability to manipulate it (without permission) to do something else through transformation or circumvention of its declared API. The default security policy today is already more restrictive than it was a couple of versions ago, and we expect it to become even more restrictive. — Ron > On 2 Aug 2021, at 11:33, Peter Firmstone wrote: > > Hello Andrew, > > I think you may be misinterpreting my comment, let me clarify: > > I'm assuming that during the process of removal of security manager, any > external ports or process hooks that we can only turn off now by not granting > a permission will be replaced by a command line property or something > similar? Eg, Agents, Management, etc. If this is the case, it would be nice > if they were set to off by default, such that they needed to be enabled from > the command line. It's a suggestion. So configuration is secure by > default. Eg, similar to how OpenBSD is configured secure by default, is that > something RedHat does? I used RedHat back in the 90's, it was my first > Linux distro, on sparc. :) > > For example, the permissions granted in this policy file: > > https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new__;!!ACWV5N9M2RV99hQ!cVJkwzysH02ZFZWT3rnO_o5viWUCBTm9nnM50QaJ5G9hsg9B3p2naDVYknIrqSNURQ$ > > Ensure that anything that isn't specifically granted, is switched off, eg > agents, management, etc. > > This file is generated by a policy writing tool, the comments in the policy > file, indicate the tests that were run to generate the policy. It's > important to note that we aren't using sandboxing, or isolation, we are > simply running with privileges we don't require switched off. All network > entry points to the JVM require authentication and classes loaded, or data > parsed requires authentication first. > > In my software without SM, authentication isn't required, and there are no > defenses against parsing un-trusted data or downloading and loading malicious > classes. Although you've made it clear, you think this is a /special case/ > and /special loss/ you needn't concern yourself with and that's fine, you've > made your point. > > In future it will not be possible to switch these features off using policy > files, so I imagine that OpenJDK must be considering alternative methods to > switch off features that may be security sensitive? > > We already know de-serialization can be switched off from the command line > using: -Djdk.serialFilter=!*, > > However if you switch off java de-serialization, you best be sure to > initialize the serialization framework when starting your JVM, as SM won't be > there to stop it being turned back on, if it's not used, it's not > initialized, then the property can be changed and is potentially a link in a > gadget chain attack where serialization can be re-enabled. :) Just saying. > > Not sure what canard you're referring to, is the JDK config secure by > default? If so, then it won't be possible for a malicious java attachment in > an email (or an image file) to be run inadvertently and use the attach API to > steal secrets. Although it's processor could be subject to speculative > execution attacks. > > A good reason to use OpenBSD (or Solaris perhaps) on Sparc for secure > systems? I know RedHat is into supporting military application in a big > way, but I'm surprised if they're not concerned about speculative execution > vulnerabilities. > > Speculative execution attacks will eventually be addressed in processor > architectures, they are trying, we shouldn't assume that we don't need to > program defensively because the underlying architecture has speculative > execution bugs. If we do that, then were do we stop? > > Anyway, if possible I would like to get back to discussing how to instrument > the Java API using Agents, and whether we can coordinate removal of > finalizers with SM removal. > > Of course if you'd like to keep SM and cancel JEP 411, as Uwe suggested, I'd > support that. I'm also grateful that Uwe spoke up, and I hope others do as > well, so this topic receives further productive discussion. It would be nice > to sort the use cases prior to SM
Re: [External] : RE: JEP 411, removal of finalizers, a path forward.
Hi. JEP 411 says that there is a feature whose value in fulfilling its purpose no longer justifies its high cost, and so it should be removed. What you’re saying is, that’s true, but you should keep it, anyway. Why? Because it can be put to some other, more modest, accidental uses. Now, the "disaster" of removing any feature is directly felt by those who use it, but the "disaster" of *not* removing it is less visible, even though it may be the bigger disaster, as we believe is the case here. Sure, we must consider those applications that use it and how they use it, but we must also consider all those that do not. By not acknowledging those who lose from keeping that mechanism, you're not appreciating the problem that the JEP tries to address. For example, you say you care about non-security uses of SM, but maintaining it comes at the cost of other security measures, and we believe that removing it would improve Java's security overall. While some of the features you say you want could well be addressed by cheaper mechanisms that could reasonably be added, it's possible that some cannot (or not fully). Thankfully, the JDK is flexible and hackable enough — through things like Java Agents — that the cost of some capabilities could be borne by those who need them. It's perfectly reasonable to explain what functionality would be helpful to you. It is not reasonable to demand keeping some functionality regardless of its cost. The reality is that to adapt to changing circumstances, the JDK must both add new capabilities as well as drop old ones, or its complexity, and, with it, its maintenance cost would grow without bound. Of course, any help in finding the right balance of cost and benefit in consideration of the needs of the *entire* ecosystem would be appreciated. P.S. Loom has nothing to do with JEP 411. I might have mentioned it when pointing out that virtually all relevant Java features developed in the past decade -- like parallel streams, CompletableFuture, and Loom -- have chosen not to integrate with SM. — Ron > On 1 Aug 2021, at 15:28, Uwe Schindler wrote: > > Hi Andrew, > >>> I'm working on the assumption that OpenJDK will close any external holes >>> currently defended by permission checks. It would be good if the JDK >>> was secure by default, with properties required to be set for allowing >>> such things as agents, management, parsing xml and serialization. >> >> You need to stop repeating this canard. There is no absolute need for >> OpenJDK to retain a security mechanism to deal with problems that for >> almost every use case are better solved by using non-OpenJDK >> alternatives (such as OS security measures). Indeed, it's the other way >> round: there is an imperative for the project to spend precious >> resources on alternative capabilities (not necessarily security related). > > Sorry, as another open source project affected by the stupid JEP 411 desaster > I would like to fully confirm to EVERYTHING that Peter said. It is not a > canard, it is the reality and I am really disappointed what happened. > > What I figured out: You intend to remove SecurityManager because it does not > fit your latest ideas how Java threads should behave. I know the main problem > is not "SecurityManager is too complex / too slow / wrongly used /..." -- the > main problem of some OpenJDK people around the Loom project is that it won't > work correctly with those new type of threads. You are now always arguing > against use cases of SecurityManager for the purpose of secuirty because you > just want to hide that the new "light" threads (aka fibers) in project Loom > are incompatible to the stack-based access control provided by > AccessController and SecurityManager. So the only canard is Project Loom - > sorry! > > So I will do the same: repeat the same story like Peter's over an over. Two > large projects affected by your changes are Apache Solr and Elasticsearch. > Both use security manager not only for security purposes, but also to control > access to resources and classloading! Speed is also no issue if you use > security manager correctly. In Apache Lucene/Solr/Elasticsearch there is NO > slowdown visible as the hooks into security manager are only called for > uncritical places (like opening a file before mmapping it, open a listening > socket, loading a class...). > > The problem is: you deprecate for removal without offering any API to replace > the main pain points: > - preventing exit of JDK > - an API to control class loading and prevent code from calling > Method/Field/Constructor#setAccessible(true) for specific cases (e.g., you > want a scripting language like Groovy to not allow caling > sun.misc.Unsafe,...). Those things can never be done with code outside of the > JVM! > - Allow to hook into the I/O system. Unfortunately the java.nio FileSystem > API is not enough: it does not cover java.io.File (why is this the case?) nor > does the FileSystem API
Re: JEP 411, removal of finalizers, a path forward.
On 8/2/21 8:28 PM, Peter Firmstone wrote: In JGDMS without SM, at least the following must be addressed to maintain security: 1. TLS and Kerberos connections cannot be established. (My software is littered with doPrivileged calls that preserve the Subject, we don't have anon TLS connections, we require client certificates). As mentioned several times, this use case will be preserved and is already covered in JEP 411: https://openjdk.java.net/jeps/411#subject-doas 2. All remote connections are authorized to load classes. Not sure why you can't do something with a custom ClassLoader that only loads classes for authorized users. 3. All remote connections are authorized to perform deserialization. Depending on serialization long-term seems somewhat dubious. Having established that OpenJDK is not yet willing to compromise, I have been attempting to create an authorization layer using Agents, so that I can restore perimeter security following the removal of SM and support future versions of Java. It is my hope that either I will be successful in recreating an authorization layer, or that enough people come forward and OpenJDK decides there are enough affected developers to find a compromise that either makes migration practical, or less expensive. You may have some interesting ideas, but in my opinion you have not presented them in a clear and easily digestible manner, and your long emails are time consuming to read, repetitive and often diverge into rants. (Keep in mind there are many people on the jdk-dev alias, and a lot of them may not care about this topic). It is to the point where I only skim your emails quickly. I would take the time to write up your ideas in an external place. It may not go anywhere, but at least you would have a single place where your proposal, experiments, etc are documented. --Sean
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
Can you think of any workable alternative compromises?
On 3/08/2021 9:21 pm, Ron Pressler wrote:
What you are proposing is:
1. Add an SPI for deep permission checks in the JDK.
2. Do so by changing the behaviour of existing classes in a non-trivial way.
3. Keep access checks in the JDK.
I do not speak for those who work on the security mechanisms, but I believe
that none one of these,
even in isolation, would be reasonable.
For one, even without the principle against changing the behaviour of existing
classes in drastic
and non-trivial ways, without the use of doPrivileged in the JDK,
AccessController would make
a bad API.
That's true, it would better if those doPrivileged calls to remain. An
alternative I thought about if they were removed, was to treat a thread
as privileged if all domains on the thread stack were resolvable from
the bootstrap ClassLoader.
For another, the cost of SM isn’t in the lines of code that make up the
AccessController implementation
but in the fact that the JDK does access checks and privileged operations in
the first place, as those
impose a tax on everything, and also take resources away from what we believe
is more robust and effective
security.
Yes, I realise this, however I'm not looking to replace all permission
checks, just the most common. Perhaps then a static method added to a
class, without implementation would be better, in cases where it's not
practical to instrument the JVM. Such that it does nothing by default
and would be optimised away by hotspot.
eg:
static instrumentGuard(String [] args) throws SecurityException{}
Thanks,
Peter.
The starting point isn’t removing the policy file implementation, but removing
all access checks
and privileged operations from the JDK, and everything else follows from there
(it will take a long
time until API elements are actually removed, anyway). Even if someone might
choose to contemplate adding
callbacks to one or two I/O operations, it is not the intent for the JDK to
participate in a general access
checking mechanism deep in its guts in addition to strong encapsulation; quite
the opposite.
— Ron
On 3 Aug 2021, at 10:44, Peter Firmstone wrote:
Thanks Ron, reply inline.
On 3/08/2021 6:48 pm, Ron Pressler wrote:
On 3 Aug 2021, at 06:48, Peter Firmstone
wrote:
We can still use these without an SM, Policy or Permissions for authorization
decisions, as mentioned previously I'd replace the inherited thread context
with an unprivileged context, and also allow the stack walk to be disabled for
people only using Subject.
I think what you mean is that you can envision using the same API points for a
different, but reasonably similar
role to the one they have. But that would mean changing the behaviour of
existing classes, possibly making some
final classes non-final, in non-trivial ways.
I'd limit changes to:
• Make the stack walk optional (via command line argument to disable
it).
• Remove Thread's inherited context, replace it with an unprivileged
context.
This would allow us to use the API for virtual threads, eg to obtain Subject
credentials to authenticate TLS connections.
It also means that for someone implementing guard checks, that these only need
check the thread stack back to the last doPrivileged call, or the start of the
thread, in the latter case it will have no privileges. It fixes the viral
permission check problem, usually doPrivileged calls are short and sweet.
It may require the addition of doPrivileged calls where they're currently
missing (and should have been used), where they've been responsible for viral
permission checks.
Just performed a search for java.security.AccessController on GitHub, got
1,398,418 results for Java:
The plan is to degrade these into no-ops until such time as most of those
usages disappear, not to imbue
those lines of code with new meaning. The actual removal of the API elements
might be a long way off,
but, becoming no-ops before then, the JDK and libraries will be free to remove
those usages.
No new meanings, the same as they have now is sufficient, just we leave the
granularity of the checks to the developers of guards and provide a means by
which guards can be registered for common check points that developers request
(perhaps via a poll), rather than all existing permission check points.
Keeping in mind that we are not trying to isolate code, but perform
authorization access checks, as well as provide credentials for authentication.
For example, if someone is only concerned with stopping the JVM from exiting,
then they only implement a guard for that particular hook, the actual code that
needs to call System::exit, then calls a doPrivileged method before doing so.
The guard need only check the domain on the stack is the one it expects, which
could be based on Principal, CodeSource, Module or ClassLoader etc, they may
also chose to implement something more complex.
Someone
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
Wow, thanks Andrew,
There's certainly some complexity there, I appreciate your guidance.
Regards,
Peter.
On 3/08/2021 7:11 pm, Andrew Dinn wrote:
On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for
line numbers in code, for exceptions etc, how are these affected when
instrumenting?
For Byteman I use ASM to inject bytecode sequences into methods
without any (significant) modification to existing bytecodes. ASM
successfully adjusts line number info to allow for the injected code
without the need for my agent to take any action.
I also add extra exception handling around injected regions and
propagate exceptions through enclosing regions to an outer handler.
ASM updates the exception table according to where the method visitor
notifies new try and catch region boundaries while retaining the
regions determined by existing notifications.
ASM provides mechanism for more complex cases. If you are rewriting
existing bytecodes or exception regions then you can use the ASM
visitor pattern to process and then renotify both line numbers and try
catch boundaries as you visit the bytecode stream. Of course, the
logic of how to do that can be as complex as (or more so than) the
rewrite logic.
n.b. Remapping exception regions at load time is tricky for two
reasons. Firstly, you cannot afford to load exception classes to
investigate the exception class hierarchy without losing the
opportunity to transform the exception class's bytecode. So, you have
to identify exception shadowing by parsing the bytecode as a resource
to establish exception super relationships. Secondly, if you tinker
with or inject extra try regions you need to a) ensure they are
properly nested inside containing try regions b) make sure that new
exception exit paths out of synchronized regions include monitorexits.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
Thanks Ron, reply inline. On 3/08/2021 6:48 pm, Ron Pressler wrote: On 3 Aug 2021, at 06:48, Peter Firmstone wrote: We can still use these without an SM, Policy or Permissions for authorization decisions, as mentioned previously I'd replace the inherited thread context with an unprivileged context, and also allow the stack walk to be disabled for people only using Subject. I think what you mean is that you can envision using the same API points for a different, but reasonably similar role to the one they have. But that would mean changing the behaviour of existing classes, possibly making some final classes non-final, in non-trivial ways. I'd limit changes to: 1. Make the stack walk optional (via command line argument to disable it). 2. Remove Thread's inherited context, replace it with an unprivileged context. This would allow us to use the API for virtual threads, eg to obtain Subject credentials to authenticate TLS connections. It also means that for someone implementing guard checks, that these only need check the thread stack back to the last doPrivileged call, or the start of the thread, in the latter case it will have no privileges. It fixes the viral permission check problem, usually doPrivileged calls are short and sweet. It may require the addition of doPrivileged calls where they're currently missing (and should have been used), where they've been responsible for viral permission checks. Just performed a search for java.security.AccessController on GitHub, got 1,398,418 results for Java: The plan is to degrade these into no-ops until such time as most of those usages disappear, not to imbue those lines of code with new meaning. The actual removal of the API elements might be a long way off, but, becoming no-ops before then, the JDK and libraries will be free to remove those usages. No new meanings, the same as they have now is sufficient, just we leave the granularity of the checks to the developers of guards and provide a means by which guards can be registered for common check points that developers request (perhaps via a poll), rather than all existing permission check points. Keeping in mind that we are not trying to isolate code, but perform authorization access checks, as well as provide credentials for authentication. For example, if someone is only concerned with stopping the JVM from exiting, then they only implement a guard for that particular hook, the actual code that needs to call System::exit, then calls a doPrivileged method before doing so. The guard need only check the domain on the stack is the one it expects, which could be based on Principal, CodeSource, Module or ClassLoader etc, they may also chose to implement something more complex. Someone else may only be concerned with network connections, so they only implement and register a guard for that. So basically we don't dictate how to implement guards or policy, we just leave enough in place, to ensure that a minimalist authorization access control api is common among all implementations on all Java versions. It is suitable, for Subject's only or code and Subject's. The doPrivileged call simply indicates the code is requesting to do something that might be privileged, or needs to provide credentials for authentication, as it does now, but it's the light version of the stack walk, if doPrivileged is not called, then the context will have an unprivileged domain on the stack (that initialized when Thread was created.). It's also possible to register guards that do fine grained permission checks, similar to the way Java does now. Then there's the use case, or registering no guards at all, and disabling the stack walk, and only using the api to obtain and preserve Subject credentials for authentication. You can trust me on this one, I'm experienced with the current API and have pushed it to all sorts of limits. Cheers, Peter.
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for line
numbers in code, for exceptions etc, how are these affected when
instrumenting?
For Byteman I use ASM to inject bytecode sequences into methods without
any (significant) modification to existing bytecodes. ASM successfully
adjusts line number info to allow for the injected code without the need
for my agent to take any action.
I also add extra exception handling around injected regions and
propagate exceptions through enclosing regions to an outer handler. ASM
updates the exception table according to where the method visitor
notifies new try and catch region boundaries while retaining the regions
determined by existing notifications.
ASM provides mechanism for more complex cases. If you are rewriting
existing bytecodes or exception regions then you can use the ASM visitor
pattern to process and then renotify both line numbers and try catch
boundaries as you visit the bytecode stream. Of course, the logic of how
to do that can be as complex as (or more so than) the rewrite logic.
n.b. Remapping exception regions at load time is tricky for two reasons.
Firstly, you cannot afford to load exception classes to investigate the
exception class hierarchy without losing the opportunity to transform
the exception class's bytecode. So, you have to identify exception
shadowing by parsing the bytecode as a resource to establish exception
super relationships. Secondly, if you tinker with or inject extra try
regions you need to a) ensure they are properly nested inside containing
try regions b) make sure that new exception exit paths out of
synchronized regions include monitorexits.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
On 3/08/2021 6:31 pm, Ron Pressler wrote: On 3 Aug 2021, at 02:30, Peter Firmstone wrote: I am still hopeful that OpenJDK might create some hooks for us and keep the AccessController, AccessControlContext and Subject.doAs methods to make supporting all Java versions easier. When I mentioned “hooks” I was referring to something along the lines of a callback when a file is accessed. Can you elaborate? A Runnable, similar to registering a shutdown hook? Just curious, when using Agents, what are the recommendations for line numbers in code, for exceptions etc, how are these affected when instrumenting? When you transform a class, you basically replace its content with new content, so the short answer is that what happens to line numbers is whatever you want. If you’re using ASM for your transformation and ignore line numbers, which ASM represents as a kind of no-op instructions, then what would usually happen is that if original instruction X is mapped to line N and when transforming the stream you replace X with YXZ, then all of YXZ will remain mapped to line N. Ok, Currently my experience with ASM is finding dependencies, and unpacking the pack200 format. I hadn't stopped to consider what it might do to line numbers. Cheers, Peter.
