Re: [External] : Re: JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

Just thought I'd share some thoughts around a couple of statements in 
JEP 411:


   *|java.security.{AccessController, AccessControlContext,
   AccessControlException, DomainCombiner}|* — The primary APIs for the
   access controller, which is the default implementation to which the
   Security Manager delegates permission checks. These APIs do not have
   value without the Security Manager, since certain operations will
   not work without both a policy implementation and access-control
   context support in the VM.

   *|javax.security.auth.SubjectDomainCombiner|* and
   *|javax.security.auth.Subject::{doAsPrivileged, getSubject}|* — APIs
   for user-based authorization that are dependent on Security Manager
   APIs such as |AccessControlContext| and |DomainCombiner|. We plan to
   provide a replacement API
    for
   |Subject::getSubject| since it is commonly used for use cases that
   do not require the Security Manager, and to continue to support use
   cases involving |Subject::doAs| (see below
   ).

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.


The advantage of retaining these methods, is that where these are used 
to preserve context for establishing TLS and Kerberos connections, they 
continue to function, even without SM or policy.


They are also a standard API for an authorization layer, for those 
wishing to re-implement it.


Just performed a search for java.security.AccessController on GitHub, 
got 1,398,418 results for Java:


https://github.com/search?l=Java=desc=3=java.security.AccessController+extension%3A.java+language%3AJava+language%3AJava+language%3AJava+language%3AJava=indexed=Code

An example of how DomainCombiner provides access to the underlying 
ProtectionDomain's on the stack.  We don't need to call 
ProtectionDomain::Implies(Permission) to make authorization decisions.


https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java

--
Regards,
 
Peter





On 3/08/2021 11:30 am, Peter Firmstone wrote:

Thanks Ron,

What we do now is dynamic, so we need to figure out how to replicate 
that post SM.  Things we don't grant dynamically are good candidates 
for command line argument options.


We basically authenticate, then authorize class loading dynamically at 
runtime, along with other things, such as deserialization (not to be 
confused with Java Serialization) and network connections. The dynamic 
grants are removed by garbage collection. Dynamic grants are probably 
very rare for most developers, although OSGi also supports dynamic 
grants also, I had a discussion with Peter Kriens around OSGi dynamic 
grants some years ago.


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. Also replacing 
thread inherited context, with an unprivileged context would be good 
too.  Then remove all the permission implementations and we could use 
the hooks we need.  The hooks could simply be an empty static method 
that's not subject to change, so we can instrument it with our own 
implementation and it gets optimized out at runtime if not used by 
hotspot.  Clearly if there are alternative mechanisms available from 
the command line that we don't need to dynamically enable, then they 
are preferable to adding clutter to policy files.   The existing 
policy provider can be removed, so we can strip it down to just the 
essential minimum components, which removes much of the testing 
required by OpenJDK.


Just curious, when using Agents, what are the recommendations for line 
numbers in code, for exceptions etc, how are these affected when 
instrumenting?


Quite happy to contribute time to adding hooks and removing other 
components.


Regards,

Peter.

On 2/08/2021 9:00 pm, Ron Pressler wrote:
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 

Re: [External] : Re: JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

Thanks Ron,

What we do now is dynamic, so we need to figure out how to replicate 
that post SM.  Things we don't grant dynamically are good candidates for 
command line argument options.


We basically authenticate, then authorize class loading dynamically at 
runtime, along with other things, such as deserialization (not to be 
confused with Java Serialization) and network connections. The dynamic 
grants are removed by garbage collection. Dynamic grants are probably 
very rare for most developers, although OSGi also supports dynamic 
grants also, I had a discussion with Peter Kriens around OSGi dynamic 
grants some years ago.


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. Also replacing thread 
inherited context, with an unprivileged context would be good too.  Then 
remove all the permission implementations and we could use the hooks we 
need.  The hooks could simply be an empty static method that's not 
subject to change, so we can instrument it with our own implementation 
and it gets optimized out at runtime if not used by hotspot.  Clearly if 
there are alternative mechanisms available from the command line that we 
don't need to dynamically enable, then they are preferable to adding 
clutter to policy files.   The existing policy provider can be removed, 
so we can strip it down to just the essential minimum components, which 
removes much of the testing required by OpenJDK.


Just curious, when using Agents, what are the recommendations for line 
numbers in code, for exceptions etc, how are these affected when 
instrumenting?


Quite happy to contribute time to adding hooks and removing other 
components.


Regards,

Peter.

On 2/08/2021 9:00 pm, Ron Pressler wrote:

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 

Re: JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

Hello Andrew,

Loss of SM is a significant threat to my software, if left unresolved.

Your interpretations are your own, I make no apologies for your 
interpretation.  I am describing the difficulties that I am experiencing 
with JEP 411 migration and how it applies to my situation, it appears 
that others are having difficulties that they have also expressed on 
OpenJDK lists, please understand that it is not a trouble free 
experience, and as such some of my frustrations may leak through into my 
writing.  In my world, more developers are affected, than are 
unaffected, but those are my associations, not yours, your experiences 
may differ from mine.


What I have stated, is that existing deployed software that uses SM for 
authorization access controls, has been designed around SM and will 
become insecure if SM is removed.   I refer you to the following book, 
which our software security architecture is designed around, I have not 
done research on the number of developers or projects affected (I do not 
have the time or resources).  I do see quite a number of developers from 
various projects have stated they will be affected in some way or 
another on OpenJDK lists, have you followed any up off list, to 
understand how they're impacted?   Or have you written them off as 
/special case/ /special loss/ ?


https://www.oracle.com/java/technologies/javaee/api-design-implementation.html

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).
2. All remote connections are authorized to load classes.
3. All remote connections are authorized to perform deserialization.

This doesn't take into account user authorization, with SM gone, it also 
means that all users and services now have all privileges.  I'm only 
documenting the major ones here.


With SM all the above require authorization and authentication, such 
that all remote connections are trusted and without malicious intent.


I have also presented a number of different compromises, that I thought 
might address some of the maintenance cost burdens around SM OpenJDK 
has, so that we might retain the most expensive components to replace.


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.


I have previously offered to donate code to OpenJDK, but I was unable to 
get clarification on whether I could include AL2.0 licensed code from 
other authors, as my code is not my sole works, two of whom have since 
passed away (only one at the time).  The remaining authors, I can still 
get in touch with and request them to sign a contributor agreement, 
which I myself have signed.   I can separate out the parts which I am 
the sole author.  For example my RFC 3986 & RFC 5952 URI implementation 
is derived from Apache Harmony under AL2.0.   This work has been in 
production for many years, and had no issues with the modules added in 
Java 9, which allowed me to use common policy files in my tests for all 
supported Java versions.  It's used in both a ClassLoader and a Policy 
implementation to avoid unnecessary DNS calls.  I have noticed that 
OpenJDK contains code under the AL2.0 license.


This has been a very frustrating experience, I'd suggest, if you haven't 
got anything of value to add, or cannot be part of the solution, please 
don't become part of the problem.  I'm doing the best I can to work 
within constraints to find a solution and am trying not to be part of 
the problem by allowing my frustration leak through, I've deleted more 
than I've posted, I suggest you do the same and direct your attack onto 
problems, rather than people.


Thank you.

Peter.

On 2/08/2021 11:07 pm, Andrew Dinn wrote:

On 02/08/2021 11:33, Peter Firmstone wrote:

I think you may be misinterpreting my comment, let me clarify:


Really? I'd suggest only if you stretch the meaning of your words 
beyond their elastic limit.


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. 
. . .
They might be or they might not be replaced -- and, 

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

[David Holmes]

On 3/08/2021 2:25 am, Igor Ignatyev wrote:

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev  wrote:


Hi all,

could you please review this big tedious and trivial(-ish) patch which moves 
`sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?

the majority of the patch is the following substitutions:
  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`

testing: tier1-4

Thanks,
-- Igor


Igor Ignatyev has refreshed the contents of this pull request, and previous 
commits have been removed. The incremental views will show differences compared 
to the previous content of the PR. The pull request contains 12 new commits 
since the last revision:

  - fixed ctw build
  - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
  - updated requires.VMProps
  - updated TEST.ROOT
  - adjusted hotspot source
  - added test
  - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
  - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
  - removed sun/hotspot/parser/DiagnosticCommand
  - deprecated sun/hotspot classes
disallowed s.h.WhiteBox w/ security manager
  - ... and 2 more: 
https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860


Hi David,


This set of changes seems much more manageable to me.


thank you for your review, David.


Not sure about the new deprecation warnings for the old WB classes .. might 
that not itself trigger some failures? If not then I don't see how the 
deprecation warnings help with transitioning to the new WB class?


the deprecation warnings (hopefully) will help people not to forget that they 
should use the new WB class in new tests.


If the test passes it is unlikely people will actually notice these in 
the jtr file - and even if they see them they may just ignore them 
thinking they are similar to all the security manager warnings that we 
ignore.


But as long as it does no harm.

Cheers,
David


Thanks,
-- Igor

Hi Jie,

Shall we also update the copyright year like 
test/lib/sun/hotspot/cpuinfo/CPUInfo.java?


we most certainly shall, just pushed the commit that updates the copyright 
years in the touched files.

Cheers,
-- Igor

-

PR: https://git.openjdk.java.net/jdk17/pull/290

[jdk17] Integrated: 8067223: [TESTBUG] Rename Whitebox API package

[Igor Ignatyev]

On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev  wrote:

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves 
> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: ada58d13
Author:Igor Ignatyev 
URL:   
https://git.openjdk.java.net/jdk17/commit/ada58d13f78eb8a240220c45c573335eeb47cf07
Stats: 532 lines in 36 files changed: 449 ins; 0 del; 83 mod

8067223: [TESTBUG] Rename Whitebox API package

Reviewed-by: dholmes, kvn

-

PR: https://git.openjdk.java.net/jdk17/pull/290

RFR: 8271566: DSA signature length value is not accurate in P11Signature

[Martin Balao]

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

-

Commit messages:
 - 8271566: DSA signature length value is not accurate in P11Signature

Changes: https://git.openjdk.java.net/jdk/pull/4961/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4961=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271566
  Stats: 242 lines in 3 files changed: 169 ins; 6 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4961.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4961/head:pull/4961

PR: https://git.openjdk.java.net/jdk/pull/4961

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

[Igor Ignatyev]

On Mon, 2 Aug 2021 15:56:39 GMT, Vladimir Kozlov  wrote:

> I agree with these revised changes for JDK 17.

Thanks for your review, Vladimir. 

I'll rerun my testing before integrating (just for good luck).

-- Igor

-

PR: https://git.openjdk.java.net/jdk17/pull/290

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v3]

[Igor Ignatyev]

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves 
> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with two additional 
commits since the last revision:

 - copyright update
 - fixed typo in ClassFileInstaller

-

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/290/files
  - new: https://git.openjdk.java.net/jdk17/pull/290/files/237e8860..fcaf41f8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17=290=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=290=01-02

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290

PR: https://git.openjdk.java.net/jdk17/pull/290

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

[Igor Ignatyev]

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev  wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves 
>> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has refreshed the contents of this pull request, and previous 
> commits have been removed. The incremental views will show differences 
> compared to the previous content of the PR. The pull request contains 12 new 
> commits since the last revision:
> 
>  - fixed ctw build
>  - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
>  - updated requires.VMProps
>  - updated TEST.ROOT
>  - adjusted hotspot source
>  - added test
>  - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
>  - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
>  - removed sun/hotspot/parser/DiagnosticCommand
>  - deprecated sun/hotspot classes
>disallowed s.h.WhiteBox w/ security manager
>  - ... and 2 more: 
> https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860

Hi David,

> This set of changes seems much more manageable to me.

thank you for your review, David.

> Not sure about the new deprecation warnings for the old WB classes .. might 
> that not itself trigger some failures? If not then I don't see how the 
> deprecation warnings help with transitioning to the new WB class?

the deprecation warnings (hopefully) will help people not to forget that they 
should use the new WB class in new tests. 

Thanks,
-- Igor

Hi Jie,
> Shall we also update the copyright year like 
> test/lib/sun/hotspot/cpuinfo/CPUInfo.java?

we most certainly shall, just pushed the commit that updates the copyright 
years in the touched files.

Cheers,
-- Igor

-

PR: https://git.openjdk.java.net/jdk17/pull/290

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

[Vladimir Kozlov]

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev  wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves 
>> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has refreshed the contents of this pull request, and previous 
> commits have been removed. The incremental views will show differences 
> compared to the previous content of the PR.

I agree with these revised changes for JDK 17.

-

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/290

Re: JEP 411, removal of finalizers, a path forward.

[Andrew Dinn]

On 02/08/2021 11:33, Peter Firmstone wrote:

I think you may be misinterpreting my comment, let me clarify:


Really? I'd suggest only if you stretch the meaning of your words beyond 
their elastic limit.


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. . . .
They might be or they might not be replaced -- and, indeed, you are 
welcome to help the project to make that a possibility. However, even if 
they were not replaced or enabled as default behaviours the platform 
would not fail to be 'secure by default'. At worst, it might be lacking 
belt and braces when it comes to available means for enforcing some 
specific forms of control over execution -- controls that can be used to 
resolve some security problems, but not exclusively. Yet, you keep using 
language that implies the loss of the security manager is a significant 
threat to the security of OpenJDK/Java.


Claiming now that all you meant was that you would like to have APIs 
that give you similar mechanisms to what is being removed does not was 
and will not validate the use of such exaggerated language. Nor do such 
statements give anyone confidence that you are able to identify clear 
and compelling requirements and assess the effort that might be needed 
to satisfy them and maintain an implementation.


So, maybe you should just stop making out that your concerns are a major 
problem to most developers and that they threaten the integrity of the 
platform and instead concentrate on identifying simple and maintainable 
APIs that we can feasibly add to OpenJDK without incurring an 
unjustifiable maintenance burden.


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: JEP 411, removal of finalizers, a path forward.

[Andrew Haley]

On 8/2/21 8:49 AM, Peter Firmstone wrote:
> If I fix that bug, will JEP 411 be cancelled?

No. The problem wasn't that we couldn't fix the [Speculative Execution
Vulnerabilities], more that any fix would be so invasive and pervasive
that it would severely hamper the whole platform.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

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://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new

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 
removal.   JEP 411 appears symbolic at this stage anyway, more JEP's 
will be created for it's disablement I believe.


Regards,

Peter.

On 2/08/2021 7:17 pm, Andrew Dinn wrote:

On 01/08/2021 15:28, Uwe Schindler wrote:

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.


Sorry, Uwe, but the canard *is* right there in the comment I quoted 
from Peter's email i.e. the bogus implication that without the 
security manager the JDK is not 

Re: JEP 411, removal of finalizers, a path forward.

[Andrew Dinn]

On 01/08/2021 15:28, Uwe Schindler wrote:

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.


Sorry, Uwe, but the canard *is* right there in the comment I quoted from 
Peter's email i.e. the bogus implication that without the security 
manager the JDK is not 'secure by default'. Irrespective of how useful 
the security manager is to your project it is utter steer manure to 
claim that without it there is a serious security hole.


That's not to say different measures may need to be taken by some 
applications, yours included. I'm not denying that. However, I'm not 
going to back down when it comes to objecting to the lack of 
proportionality in Peter's claims.


I believe Alan has answered your rather speculative follow-up comments 
so I'll rest on that clarification.


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: JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

Thanks Florian,

1. If I fix that bug, will JEP 411 be cancelled?   BTW. Sparc isn't
   vulnerable.
2. My primary use case is for SM is for authorization decisions for
   remote users and services.

JSR-121: Java Application Isolation API Specification.

http://apt.cs.manchester.ac.uk/intranet/csonly/jamaica/j2se_isolate-1_0-prd-spec/docs/java/lang/isolate/package-summary.html

People keep confusing isolation with authorization, these aren't the 
same thing, Isolates were designed for Isolation, which never made it 
into Java SE and AccessController was designed for authorization access 
controls.  Other access controls are part of the language, such as 
public, private, protected modifiers etc.


Applets had a weak form of isolation using ClassLoader's, and had 
permissions to connect to their originating network address.  I don't 
think anyone has developed Applets for at least 10 years?


I'm talking about currently maintained software that uses SM for 
authorization decisions and am looking for ways to re-implement 
authorization in JDK libraries using Agents.


Often constructors contain permission guard checks, but due to finalizer 
defenses, these cannot be instrumented without instrumenting private 
static methods.  The alternative is to instrument object methods 
instead, however these would impact performance (although I'm 
considering instrumenting ClassLoader object methods).


An example of a generated grant, note how the SHA-384 signature of the 
file is captured, along with the User?  This doesn't include dynamically 
granted permissions which occur during authorization, then downloading, 
class loading and unmarshalling of a service proxy.


grant codebase 
"httpmd://${HOST}:9080/${mercury-dl.jar};sha-384=041531e5e3de288c121e865af8a46f7af86172ee0127dc4aff4f551c73a0ad604f51cb1c53076140fd415f957c14e8dd",

    principal javax.security.auth.x500.X500Principal "CN=Outrigger"
{
    permission org.apache.river.api.io.DeSerializationPermission 
"MARSHALL";
    permission net.jini.security.AuthenticationPermission 
"javax.security.auth.x500.X500Principal \"CN=Outrigger\" peer 
javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect";

};

Without SM, everyone is authorized, our network connections will allow 
everyone and anyone in, so I need to re-implement an authorization 
layer, however OpenJDK has a monopoly on Java libraries.


An alternative that isn't being considered at this stage is to remove 
support for TLS and Kerberos connections from the JDK, and use private 
virtual networks and a VM instead, however that stops global service 
discovery over IPv6, and constrains the software in many other areas as 
well, so it's not being considered at this time.


Regards,

Peter.

On 2/08/2021 4:23 pm, Florian Weimer wrote:

* Peter Firmstone:


 From our discussions, my interpretation is that OpenJDK is constrained
by corporate security policy; any issues with SecurityManager
infrastructure will be treated as confidential security issues and
have to be fixed with internal resources. Community volunteers won't
be allowed to handle them.  Hence it's the maintenance burden.  I see
this maintenance cost as a bureaucratic management issue, rather than
an issue with SM per se.

The dynamics would likely change if the community started fixing issues.

A starting point could be speculative execution vulnerabilities, which
are currently out of scope for the OpenJDK security process:

   Java and Speculative Execution Vulnerabilities
   

I think any use of the security manager for isolation purposes would
have to address those issues.

Thanks,
Florian

Re: JEP 411, removal of finalizers, a path forward.

[Florian Weimer]

* Peter Firmstone:

> From our discussions, my interpretation is that OpenJDK is constrained
> by corporate security policy; any issues with SecurityManager 
> infrastructure will be treated as confidential security issues and
> have to be fixed with internal resources. Community volunteers won't
> be allowed to handle them.  Hence it's the maintenance burden.  I see
> this maintenance cost as a bureaucratic management issue, rather than
> an issue with SM per se.

The dynamics would likely change if the community started fixing issues.

A starting point could be speculative execution vulnerabilities, which
are currently out of scope for the OpenJDK security process:

  Java and Speculative Execution Vulnerabilities
  

I think any use of the security manager for isolation purposes would
have to address those issues.

Thanks,
Florian

Re: JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

On 2/08/2021 4:48 am, Alan Bateman wrote:


On 01/08/2021 15:28, Uwe Schindler wrote:

:
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!
This isn't right, I don't know where you got that. The only connection 
to threads is the unspecified capturing of an access control context 
at Thread create time. Loom has been betting that it will be 
irrelevant and eventually removed so doesn't capture it. For the 
interim it just specifies that virtual threads have "no permissions". 


Alternatively for loom virtual threads; use an unprivileged context 
instead of inherited context.  A good choice for all threads actually, 
not just virtual.  Fixes viral permissions, Executor task 
vulnerabilities, it requires downstream developers to add doPrivileged 
methods before an application can do something that's privileged and 
reduces pain for people more focused on granting privileges to Principals.


Developers who use SM are reading JEP 411 and interpreting it as biased 
towards SM removal, so are looking for an underlying motivation for SM 
removal not stated there.  I also suspected that Loom might be the 
reason at one point.


From our discussions, my interpretation is that OpenJDK is constrained 
by corporate security policy; any issues with SecurityManager 
infrastructure will be treated as confidential security issues and have 
to be fixed with internal resources. Community volunteers won't be 
allowed to handle them.  Hence it's the maintenance burden.  I see this 
maintenance cost as a bureaucratic management issue, rather than an 
issue with SM per se.


I have previously suggested that SM infrastructure bugs not be handled 
as security issues, instead reported as authorization layer bugs, with 
any support for sandboxing removed.  If it is true what Andrew Dinn 
suggests, that OS measures are more appropriate, then these bugs don't 
need to be treated as security issues and can be downgraded, to allow 
the community using it, to maintain SM infrastructure instead.  This 
way, it doesn't impact other developers who don't use it.   If Andrew is 
correct, we can downgrade bugs in SM code, they are not security bugs in 
the traditional sense, if that isn't the case, then Andrew is likely 
incorrect.


Uwe, thanks for speaking up, the more people who speak up about their 
use of SM, as an authorization layer, rather than a sandbox for code 
with malicious intent, the less OpenJDK will consider this use of SM is 
a /special case/.


Regards,

Peter.