Re: Timeframe for JEP-411 completely removing SecurityManager APIs

[Peter Firmstone]

Hi Arjan,

Java 8 is supported until 2030, and 17 to 2029, we would be unable to 
continue testing against new Java releases.


https://bugs.openjdk.java.net/browse/JDK-8272340

With this choice, there will be incompatible Java versions we must 
prevent our software from running on, until it becomes possible to 
support a later version.


It also means that someone who wants to use new Java API's on a Java 
version we don't support may be forced to migrate away from using our 
software.   It also means that we will be unable to take advantage of 
new Java API's which may put us at a significant disadvantage.


Regards,

Peter.

On 2/05/2022 5:24 pm, arjan tijms wrote:

Hi,

On Monday, May 2, 2022, Peter Firmstone  
wrote:


I guess I'm just trying to say we need more time, the process of
extricating SM for security will take years, if we can leave SM as
it is in deprecated form for a number of years, that would be
greatly appreciated.


Just wondering, but would it not be an option to just keep using the 
last LTS that has the SM? That may well enable you to keep using the 
SM for something like 10 years?


Kind regards,
Arjan Tijms



Regards,

Peter.

On 27/04/2022 3:38 am, Sean Mullan wrote:



On 4/26/22 1:06 PM, Scott Stark wrote:

By "migration feature" I'm talking about being able to
retain the type of library code where one has a
conditional call to an AccessController::doPrivileged(...)
method that is only done when System.getSecurityManager()
is not null. Not having to remove this code in all
dependent libraries for a given Jakarta EE application
server product in order to run on Java SE 21 is seen as
necessary to navigate supporting application servers over
a range of Java SE versions. The general consensus was
that having to deal with Java SE 11, 17 and 21 would only
be possible if this SecurityManager related code could
remain as is, even if the only executed path would be
for System.getSecurityManager() == null. We can deal with
a gradual degradation of the SecurityManager behavior, but
it was unclear if Java SE 21 was looking for a complete
removal of the APIs the libraries use.


Yes, we understand these concerns. We recognize the
compatibility issues and the importance for code using the SM
APIs to continue to work as if an SM has not been enabled.
This is the motivation behind the language in the JEP that
discusses a gradual degradation and phasing out of the SM APIs
until the compatibility risk is low enough that removal is
acceptable.

Also, you mention SE 21, but as of yet there is not yet a
targeted release for the SM removal. There will likely be a
JEP for the removal of the SM and this will need to go through
several phases of the JEP process before it can be targeted to
a specific release.

I'm sure many of the Jakarta EE platform dev members have
code repositories to offer for scanning to aide in
determining when the SecurityManager dependencies have
been removed. If there is a avenue for that information,
please let me know.


Thanks for that offer. I don't have an avenue for that
information yet, but I will see if we can start creating a
list of significant SM-enabled libraries and other projects
that we can monitor over time.

--Sean

Thanks,
Scott

On Apr 26, 2022 at 11:09:22 AM, Sean Mullan
mailto:sean.mul...@oracle.com>>
wrote:

Hello Scott,

On 4/25/22 2:25 PM, Scott Stark wrote:

Hello,

I'm Scott Stark of Red Hat, and a member of the
Jakarta EE platform dev
group (EEPD). I'm currently coordinating the
Jakarta EE 10 release that
is targeting June of this year (2022). The removal
of the
SecurityManager as described in JEP-411 has been a
topic for the EEPD on
may calls this year. Recent discussions make it
clear that any
SecurityManager alternative would need to be taken
up by the EEPD, and
such an effort is going to be a non-trivial
undertaking, and may not be
addressed at all.

A general concern among vendors in the EEPD is the
timeframe for the
code that bridges between the JVM running with and
without a
SecurityManager instance needi

Re: Timeframe for JEP-411 completely removing SecurityManager APIs

[Peter Firmstone]

Our software was never designed to run without SM enabled.  We will need 
to instrument the Java API's with some access controls, this will be 
reliant on the removal of finalizers, or the option to disable them.


In our case deserialization is decided by the permission granted to the 
authenticated remote user.   Deserialization also has a number of 
different categories based on risk.   For example explicit permission is 
required to deserialize a MarshalledObject, in this case the 
MarshalledObject is only used for equals comparison, the 
MarshalledObject is never itself unmarshalled, checked by code audit 
before granting this permission.  The ability to class load remote code 
dynamically is also determined by permission.


Our software attempts to set the security manager if it hasn't been set.

We realise that this is no longer the recommended way to secure Java 
software, however our software will be insecure without SM until we can 
replace its functionality.


The problem is, OpenJDK is telling us that this is not the best way to 
secure Java, that there are better alternatives, however without SM our 
software will be insecure, until we are able to redesign it, 
unentangling our dependency on SM isn't a simple problem to solve.


I guess I'm just trying to say we need more time, the process of 
extricating SM for security will take years, if we can leave SM as it is 
in deprecated form for a number of years, that would be greatly appreciated.


Regards,

Peter.

On 27/04/2022 3:38 am, Sean Mullan wrote:



On 4/26/22 1:06 PM, Scott Stark wrote:
By "migration feature" I'm talking about being able to retain the 
type of library code where one has a conditional call to an 
AccessController::doPrivileged(...) method that is only done when 
System.getSecurityManager() is not null. Not having to remove this 
code in all dependent libraries for a given Jakarta EE application 
server product in order to run on Java SE 21 is seen as necessary to 
navigate supporting application servers over a range of Java SE 
versions. The general consensus was that having to deal with Java SE 
11, 17 and 21 would only be possible if this SecurityManager related 
code could remain as is, even if the only executed path would be 
for System.getSecurityManager() == null. We can deal with a gradual 
degradation of the SecurityManager behavior, but it was unclear if 
Java SE 21 was looking for a complete removal of the APIs the 
libraries use.


Yes, we understand these concerns. We recognize the compatibility 
issues and the importance for code using the SM APIs to continue to 
work as if an SM has not been enabled. This is the motivation behind 
the language in the JEP that discusses a gradual degradation and 
phasing out of the SM APIs until the compatibility risk is low enough 
that removal is acceptable.


Also, you mention SE 21, but as of yet there is not yet a targeted 
release for the SM removal. There will likely be a JEP for the removal 
of the SM and this will need to go through several phases of the JEP 
process before it can be targeted to a specific release.


I'm sure many of the Jakarta EE platform dev members have code 
repositories to offer for scanning to aide in determining when the 
SecurityManager dependencies have been removed. If there is a avenue 
for that information, please let me know.


Thanks for that offer. I don't have an avenue for that information 
yet, but I will see if we can start creating a list of significant 
SM-enabled libraries and other projects that we can monitor over time.


--Sean


Thanks,
Scott

On Apr 26, 2022 at 11:09:22 AM, Sean Mullan > wrote:

Hello Scott,

On 4/25/22 2:25 PM, Scott Stark wrote:

Hello,

I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform 
dev
group (EEPD). I'm currently coordinating the Jakarta EE 10 release 
that

is targeting June of this year (2022). The removal of the
SecurityManager as described in JEP-411 has been a topic for the 
EEPD on

may calls this year. Recent discussions make it clear that any
SecurityManager alternative would need to be taken up by the EEPD, and
such an effort is going to be a non-trivial undertaking, and may 
not be

addressed at all.

A general concern among vendors in the EEPD is the timeframe for the
code that bridges between the JVM running with and without a
SecurityManager instance needing to be updated. Such code is the 
subject

of this JEP-411 paragraph:

"In feature releases after Java 18, we will degrade other Security
Manager APIs so that they remain in place but with limited or no
functionality. For example, we may revise 
AccessController::doPrivileged

simply to run the given action, or revise System::getSecurityManager
always to return null. This will allow libraries that support the
Security Manager and were compiled against previous Java releases to
continue to work without change or even recompilation. We expect to
remove the APIs once the compatibility 

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

Brief comment on ECC attack below, the code download can be prevented by 
granting DownloadPermission only to code signers and not user 
principals.  In this case the imposter service would only be able to 
cause a signed code source to class-load.   Since Java serialization is 
disabled, the attacker would probably be unable to penetrate the jvm, 
but still could potentially steal data.


On 28/04/2022 3:25 pm, Peter Firmstone wrote:

Hi Martin,

Your arguments are the reasons why we use the principle of least 
privilege.   It creates a headache for attackers, similar to the 
developer who's enabled SM for the first time and must manually add 
every required permission for their software to function (who thought 
that was a good idea lol?).   The attacker requires an intimate 
knowledge of the permissions their attack vectors or gadgets require, 
including those a thread of execution has already been granted as well 
as the features that those permissions will grant the attacker access 
to.   If the thread of execution doesn't have all required 
permissions, it will cause the jvm to exit with a SecurityException.   
How does the attacker obtain all the required information?  With great 
difficulty.


As soon as the software does something a generated polp policy file 
hasn't captured, a security exception is almost inevitably thrown, 
even if it wasn't designed to protect an intended target, it almost 
inevitably gets in the way.  You will find that it's almost impossible 
to do anything unintended.  Although once you can impersonate a user 
or service, say with the recent ECC exploit, you can at least do what 
that user or service is allowed to do, but it still won't allow the 
attacker to achieve their intended end goal unless the user or has all 
the required permissions.  In our case if the attacker can impersonate 
a service, then they can load code, that's a problem, as our software 
assumes ECDSA provides strong confidentiality.  We recognise that once 
you get to the stage of loading code into the jvm, it's pretty much 
game over.   A polp policy file won't defend against the recent ECC 
exploit.


https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/ConfidentialityStrength.java 



What polp can protect against however, is an exploit in a feature that 
you don't use, it protected against the recent Log4J vulnerability.


An example of a polp policy file: 
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy


One of the improvements we can make (when re-implementing access 
controls), is to reduce the size of the jdk's trusted computing base, 
instead of having many trusted protection domains with all permission 
(characterised with a null protection domain), we can give each module 
a separate protection domain identity, and limit each only to the 
permissions required for our software to function as intended.   This 
means that jvm modules we don't use will have no permissions at all.  
To get around the large trusted jdk code base, we provided two methods 
which append a ProtectionDomain, with only the user's required 
permissions, it also prevents injection of a user Subject's 
permission's into less privileged service domains.  It's use hasn't 
really caught on though, no doubt due to complexity.


https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java#L590 



This is really a hack because the jdk's trusted computing base is too 
large, also user permissions should be granted only to protection 
domains that have the necessary user principals and code signers, to 
avoid injecting additional permissions into less privileged service 
protection domains.


All data parsing the jvm performs, should also be moved into separate 
modules, so that data parsing access controls and privileges could 
have been managed (this is one of the missing checks you mention), and 
yes it did provide a false sense of security for many years that Java 
serialization was secure when it wasn't.  I had many difficulties 
explaining to developers in 2010 that Java serialization wasn't 
secure, they didn't believe me and it cause problems.


Had the Java 2SE security infrastructure never been introduced, 
perhaps something else would have evolved, or at the very least, our 
software wouldn't depend on it.  Java's access controls have certainly 
suffered from a lack of investment.


Unfortunately our software is dependent on it and designed around it 
at a fundamental level, even if SM is null (which incidentally I've 
haven't yet tested, I think we have code that checks that SM is 
enabled), our software is still using AccessControlContext's to 
establish TLS connections and authenticate users.   Personally I would 
like to see parts of AccessController and AccessControlContext 
retained for retrieving the Subject for establishing secure

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

Hi Martin,

Your arguments are the reasons why we use the principle of least 
privilege.   It creates a headache for attackers, similar to the 
developer who's enabled SM for the first time and must manually add 
every required permission for their software to function (who thought 
that was a good idea lol?).   The attacker requires an intimate 
knowledge of the permissions their attack vectors or gadgets require, 
including those a thread of execution has already been granted as well 
as the features that those permissions will grant the attacker access 
to.   If the thread of execution doesn't have all required permissions, 
it will cause the jvm to exit with a SecurityException.   How does the 
attacker obtain all the required information?  With great difficulty.


As soon as the software does something a generated polp policy file 
hasn't captured, a security exception is almost inevitably thrown, even 
if it wasn't designed to protect an intended target, it almost 
inevitably gets in the way.  You will find that it's almost impossible 
to do anything unintended.  Although once you can impersonate a user or 
service, say with the recent ECC exploit, you can at least do what that 
user or service is allowed to do, but it still won't allow the attacker 
to achieve their intended end goal unless the user or has all the 
required permissions.  In our case if the attacker can impersonate a 
service, then they can load code, that's a problem, as our software 
assumes ECDSA provides strong confidentiality.  We recognise that once 
you get to the stage of loading code into the jvm, it's pretty much game 
over.   A polp policy file won't defend against the recent ECC exploit.


https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/ConfidentialityStrength.java

What polp can protect against however, is an exploit in a feature that 
you don't use, it protected against the recent Log4J vulnerability.


An example of a polp policy file: 
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy


One of the improvements we can make (when re-implementing access 
controls), is to reduce the size of the jdk's trusted computing base, 
instead of having many trusted protection domains with all permission 
(characterised with a null protection domain), we can give each module a 
separate protection domain identity, and limit each only to the 
permissions required for our software to function as intended.   This 
means that jvm modules we don't use will have no permissions at all.  To 
get around the large trusted jdk code base, we provided two methods 
which append a ProtectionDomain, with only the user's required 
permissions, it also prevents injection of a user Subject's permission's 
into less privileged service domains.  It's use hasn't really caught on 
though, no doubt due to complexity.


https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java#L590

This is really a hack because the jdk's trusted computing base is too 
large, also user permissions should be granted only to protection 
domains that have the necessary user principals and code signers, to 
avoid injecting additional permissions into less privileged service 
protection domains.


All data parsing the jvm performs, should also be moved into separate 
modules, so that data parsing access controls and privileges could have 
been managed (this is one of the missing checks you mention), and yes it 
did provide a false sense of security for many years that Java 
serialization was secure when it wasn't.  I had many difficulties 
explaining to developers in 2010 that Java serialization wasn't secure, 
they didn't believe me and it cause problems.


Had the Java 2SE security infrastructure never been introduced, perhaps 
something else would have evolved, or at the very least, our software 
wouldn't depend on it.  Java's access controls have certainly suffered 
from a lack of investment.


Unfortunately our software is dependent on it and designed around it at 
a fundamental level, even if SM is null (which incidentally I've haven't 
yet tested, I think we have code that checks that SM is enabled), our 
software is still using AccessControlContext's to establish TLS 
connections and authenticate users.   Personally I would like to see 
parts of AccessController and AccessControlContext retained for 
retrieving the Subject for establishing secure connections in a way 
that's compatible across all Java versions.


After removing access controls, it effectively means AllPermission is 
granted to every authenticated user (and in our case service).   Any 
access controls that we create at a higher level, can be circumvented by 
the lack of lower level access controls.   So the only access control is 
authentication.


We have no desire or want to instrument the jvm, we have been advised 
that 

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

Well said, we're not trying to sandbox untrusted code.  We're simply 
trying to provide authorization controls on authenticated users and in 
my particular case, service proxy's.   It's well known the JVM can't 
handle untrusted code, nor does it have well designed defenses against 
parsing untrusted data, all these things happen to be bolted on 
afterthoughts.


Regards,

Peter.

On 26/04/2022 11:07 pm, David Lloyd wrote:

On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman  wrote:

On 25/04/2022 13:53, David Lloyd wrote:

Nothing in the proposal causes splitting or delegation of
responsibilities. It is _only_ about preserving security checkpoints
in the JDK, which *add* a layer of checks to what the container might
already provide. Nothing is being subtracted, and thus I find it hard
to accept that preserving these checks somehow reduces security
overall.

"preserving security checkpoints in the JDK" suggests just leaving the
calls do AccessController.doPrivileged and
SecurityManager.checkPermission in place.

The proposal is clear that the JDK 'doPrivileged' calls would not be
necessary, and it is not necessary to exactly use `checkPermission`
depending on the approach taken. This might or might not counter your
argument, but as I said before, even if the proposal is rejected, it
should be rejected based on a fair and accurate evaluation of what is
proposed.


That amounts to putting a tax
on every feature, every JEP, and all ongoing maintenance of the
platform. If there is refactoring or a change that forgets to insert a
checkPermission somewhere then we have a security issue and everything
that goes along with that.

Sure, if you continue to think of SecurityManager as a sandbox, then
every case where it is not a perfect sandbox can be a major security
issue. In real terms though, was SecurityManager ever _actually_
effective as a sandbox? It is certainly the case that few (if any) of
us who do systems and security programming in application servers and
containers at Red Hat have ever considered it so. Thus, the proposal
as given tries to reflect this reality by treating the SecurityManager
as exactly two things: firstly, a central point for any application or
library to be able to statically perform an authorization check
without needing to rely on any library other than the JDK itself; and
secondly, a mechanism by which certain operations performed by the JDK
can be authorized by the user.

The lack of an authorization check would therefore be less impactful
when considered from this perspective. Maybe a security issue, yes,
but not a sandbox escape because there _is_ no sandbox. It's not a
part of the contract anymore. In fact, part of the contract could even
be an _explicit admonition_ that missing checks in the JDK would be
considered bugs but not security issues. Even that would be better
than removing the whole thing; if doing X has an unacceptable cost,
let's stop doing X instead of getting rid of Y.


I think Martin is right that hooking authorization libraries into low
level libraries isn't the right way to do this. Aside from the
complexity methods I would add that threads pools or any hand-off
between threads will typically break when the context is not carried.

Propagation of security context is not a problem that needs a solution
in the JDK and is not a part of the proposal. It's generally already a
solved problem within containers, where this feature is intended to be
used, including cases where threads are created or tasks are
dispatched to thread pools, fork/join, etc. Thus the proposal
establishes that this is 100% the responsibility of the security
manager implementation.


One other point about authorization libraries wanting to hook into low
level code is that it's a minefield of potential issues with recursive
initialization, stack overflows and some really hard to diagnose issues.
JDK-8155659 [1] is one report that comes to mind.

It is up to the implementation to deal with recursive calls into the
security manager today (and we already do so to our own satisfaction),
and I don't see any reason why that wouldn't continue to be the case.
In my opinion, this would not be an issue that the JDK has to be
concerned about (other than maybe as a documentation issue).

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

On 26/04/2022 8:10 pm, Alan Bateman wrote:

On 26/04/2022 10:06, Peter Firmstone wrote:

:

What about ensuring that all network access occurs through a single 
location that we can instrument?


Network, file, and process launch are potentially interesting but 
instrumenting them to run arbitrary code may be problematic (for the 
same reasons that custom security managers can be problematic).


-Alan


A service provider? Don't specify that's it's for security, just for 
intercepting network, file and process launching.


"can" is the key word here.    The problems are manageable when you know 
about them.  If a developer isn't aware, it could create nasty 
surprises.  So can't we document the gotchas?


Regards,

Peter.

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

On 26/04/2022 6:28 pm, Alan Bateman wrote:

On 25/04/2022 13:53, David Lloyd wrote:

Nothing in the proposal causes splitting or delegation of
responsibilities. It is _only_ about preserving security checkpoints
in the JDK, which *add* a layer of checks to what the container might
already provide. Nothing is being subtracted, and thus I find it hard
to accept that preserving these checks somehow reduces security
overall.


"preserving security checkpoints in the JDK" suggests just leaving the 
calls do AccessController.doPrivileged and 
SecurityManager.checkPermission in place. That amounts to putting a 
tax on every feature, every JEP, and all ongoing maintenance of the 
platform. If there is refactoring or a change that forgets to insert a 
checkPermission somewhere then we have a security issue and everything 
that goes along with that. No thanks!


What about ensuring that all network access occurs through a single 
location that we can instrument?


It would be nice to leave AccessController calls in place, oh well, such 
is life.





I think Martin is right that hooking authorization libraries into low 
level libraries isn't the right way to do this. Aside from the 
complexity methods I would add that threads pools or any hand-off 
between threads will typically break when the context is not carried.



Yes, we went to a lot of trouble to ensure context is preserved through 
executors and other thread calls, for executors, it was simple enough to 
decorate a Callable.   However this is successful, in that our 
RemoteEvent's and Event listeners use the preserved AccessControlContext 
to establish and authenticate secure connections.





One other point about authorization libraries wanting to hook into low 
level code is that it's a minefield of potential issues with recursive 
initialization, stack overflows and some really hard to diagnose 
issues. JDK-8155659 [1] is one report that comes to mind.


Yes, I have also come across this problem, I use a thread local to 
detect the recursion, in try finally blocks.


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

One must also be aware of class loading, to ensure necessary classes are 
loaded at the right time.


The following is an example of a complex issue, which was solved using 
immutability, by avoiding shared state between threads and avoiding 
blocking where possible.   Java's PermissionCollection implementations 
are a minefield of synchronization, so we thread confined 
PermissionCollection.   We avoided caching permission check results as 
Java's policy cache is a huge performance killer.  There is also the 
issue of DNS calls made in URL and URLClassLoader, so we fixed those 
issues too.  Instead of relying on DNS we use RFC3986 and RFC5952 
normalization.   The performance difference as you might imagine by 
removing blocking network calls and replacing it with immutable 
normalized forms was huge.


https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java#L265

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



-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8155659


It's just such a shame that we achieved so much and OpenJDK is pulling 
the rug from underneath us.


Regards,

Peter.

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

a countdown, which 
must be periodically reset, or an exception will be thrown and control returned 
to the caller when the limit is reached.

Invocation constraints also provide a way for callers to communicate their 
intent to underlying communication layers.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint/InvocationConstraints.java

Note that there are extensible layers:

1. Invocation layer
2. Object Identification layer.
3. Serialization layer.
4. Transport layer.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/package.html

These security precautions will no longer provide protection after SM is 
degraded, hence the need to re-implement an authorization layer.

I had hoped that OpenJDK might assist us by providing hooks we can use to 
control network access, creation of ClassLoader's or access to properties, or 
key stores, but it looks as though we have to instrument the Java api's and we 
are on our own.  It also appears due to finalizers, that there will be versions 
of OpenJDK which we cannot support, eg if SM has been disabled and finalizers 
are still present, we cannot support this JDK version.

Personally I'd like to see SM fully supported until finalizers can be disabled.

--
Regards,
 
Peter Firmstone

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

Hi Martin,

I'm curious, you sound like you arrived at this opinion from 
experience?  Rather than being an upper layer only concern, my opinion 
is that it requires lower layer intervention / controls, with upper 
layers providing the decision making context.


My reason for asking is, we're basically waiting for finalizers to be 
disabled, so that we can instrument the java api with access controls to 
replace SM.


In our implementation, we use the SM infrastructure like this:

1. Distributed computing - protection domains and ClassLoaders are used
   for service identity and isolation at the client. (Simplification
   because a server can also be a client and vice versa).
2. All client subjects are authenticated over secure connections,
   threads on the server are run with the client subject, from the
   client jvm, for access control decisions, eg do I trust the data
   enough to parse it?   Callbacks for client listeners (services) are
   run with the server's subject at the client.
3. We re-implemented java de-serialization, with a public api that uses
   constructors.   Unlike perl taint mode, we rely on the authenticated
   subject's principals, to determine whether to allow permission to
   deserialize (parse data).  SM allows us to handle tainted data,
   because we put permission checks into our deserialization
   implementation, if there's no authenticated subject, or the remote
   end doesn't have the required principal, then deserialization
   doesn't proceed at all, because no one vouches for the data, it
   cannot be trusted.   Our deserialization implementation provides an
   atomic input validation api, to validate data (sanitize) from
   trusted sources, in theory it would allow us to parse untrusted
   data, but we use authentication to reduce our exposure.  Rather than
   a bolted on external kind of white listing filtering mechanism, it's
   a class level implementation concern.
4. Clients dynamically download requested proxy jar files, (streams are
   not annotated like RMI), prior to download, the client authenticates
   the service's server, after authentication, the client loads the jar
   files, and deserializes the proxy object state into a designated
   ClassLoader (unique to the service identity, services that share jar
   file URI will not share ClassLoader's and don't resolve to the same
   class type). After authentication, the service provides URI and
   advisory permissions and the client may dynamically grant the
   intersection of those permissions which it has permission to grant
   and those the service requests.
5. Our services are discoverable over multicast IPv6 (globally and on
   local networks, usually the two are kept somewhat separate).
6. We have service constraints, these are upper layer controls that
   lower layers use to ensure connections use strongly encrypted TLS
   protocols for example, or that a connection can be authenticated
   with a particular principal.  If a service is obtained from another
   service, our lower layer communications ensure that the same
   constraints apply to the second service, the client may apply new
   constraints after receiving a service proxy.

JEP411's successor will remove or change the functionality of Java's 
access controls and will break all our TLS connections and our ability 
to have different levels of access control for different services.


We can of course just do some kind of no op on later versions of Java 
with missing api's via reflection, which will also disable encrypted 
connections, then we can allow services to communicate over trusted 
networks or VPN's, and allow deserialization and jar file downloads, all 
without any jvm layer security, but we lose our ability to dynamically 
discover services globally, they will need to be known in advance and 
the secure network connections established in advance.


We solved all problems with SM mentioned in JEP 411, with the exception 
of the maintenance cost for OpenJDK.  My understanding is it is company 
policy around security that makes it expensive to maintain.  We have a 
policy generation tool (based on principles of least privilege), our 
policy provider has a less than 1% performance impact.   We have a 
PermissionComparator that avoids equals calls on Permission's, we have a 
URI 3986 implementation, that also normalizes IPv6 addresses, uses 
bitshift operations for case conversions and is extremely fast, it's 
used by our ClassLoader and Policy implementations.


The only remaining irritations were the structures of the Permissions 
themselves, eg SocketPermission can't constrain communications to subnet 
IP address ranges.


What Li Gong provided was very well designed, Sun just never finished 
it, and pretty much let it rot on the vine, few people used it, because 
of the amount of work required to make it work properly, and the fact 
that security is a nice to have feature, but budget constraints and 
delivery deadlines, and now it's 

Re: RFR: 8285398: Cache the results of constraint checks

[Peter Firmstone]

Nice.

On 22/04/2022 6:47 am, Daniel Jeliński wrote:

On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński  wrote:


Profiling the TLS handshakes using SSLHandshake benchmark shows that a large 
portion of time is spent in HandshakeContext initialization, specifically in 
DisabledAlgorithmConstraints class.

There are only a few instances of that class, and they are immutable. Caching 
the results should be a low-risk operation.

The cache is implemented as a softly reachable ConcurrentHashMap; this way it 
can be removed from memory after a period of inactivity. Under normal 
circumstances the cache holds no more than 100 algorithms.

before:

Benchmark (resume)  (tlsVersion)   Mode  Cnt Score  
Error  Units
SSLHandshake.doHandshake  true   TLSv1.2  thrpt5  2165.081 ± 
440.204  ops/s
SSLHandshake.doHandshake  true   TLS  thrpt5   534.681 ± 
146.931  ops/s
SSLHandshake.doHandshake false   TLSv1.2  thrpt5   369.104 ±  
11.143  ops/s
SSLHandshake.doHandshake false   TLS  thrpt5   253.903 ±  
58.056  ops/s

after:

Benchmark (resume)  (tlsVersion)   Mode  Cnt  Score 
Error  Units
SSLHandshake.doHandshake  true   TLSv1.2  thrpt5  10440.501 ± 
478.177  ops/s
SSLHandshake.doHandshake  true   TLS  thrpt5762.995 ±  
33.842  ops/s
SSLHandshake.doHandshake false   TLSv1.2  thrpt5440.471 ±  
52.867  ops/s
SSLHandshake.doHandshake false   TLS  thrpt5305.928 ±  
57.847  ops/s

After this patch the HandshakeContext initialization practically disappears 
from the CPU profile; it only takes ~5% in TLS1.2 resumption, and much less in 
the remaining scenarios.

-

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


--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: RFR: JDK-8242888: Convert dynamic proxy to hidden classes

[Peter Firmstone]

We re-implemented a subset of Java Serialization, prior to the creation 
Java serialization filters.  Field types are read ahead from the stream 
and invariant's validated during construction for failure atomicity (a 
special constructor signature is used for deserialization), there are 
also stream limits that require periodical stream resets, to avoid 
million laugh style attacks. Also the source of the serialized data must 
be authenticated before permission is granted for parsing serial data.   
We also removed the ability to deserialize object graphs with circular 
links.


This is used for an Remove invocation framework called JERI (Jini 
extensible remote invocation).  Serialization has been given a public 
API to allow extensibility, that is to allow other serialization 
protocols to be used via configuration, using a Serialization layer.


Service and service discovery architecture makes use of JERI, for 
marshaling object parameters securely over the network, for remote 
method calls on services, via remote proxy's.


The way that JERI serializes proxy's has changed significantly since 
Jini, instead of marshaling proxy's, a bootstrap proxy (local code only) 
is marshaled first, the client first authenticates the connection, the 
bootstrap proxy is used to provide information for dynamic downloading 
of any required jar files, or wiring of dependencies prior to the 
unmarshaling of the service proxy.  Unlike Java RMI, which uses 
RMIClassLoading for class resolution, each Jeri Endpoint is assigned a 
ClassLoader for class resolution during deserialization / object 
unmarshaling, this solves the OSGi deserialzation class resolution problem.


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

https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/AtomicMarshalInputStream.java#L2263

https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/AtomicMarshalInputStream.java#L853

Would be nice to do some testing with the changes.

--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

On 18/04/2022 2:24 am, liach wrote:

Convert dynamic proxies to hidden classes. Modifies the serialization of proxies 
(requires change in "Java Object Serialization Specification"). Makes the 
proxies hidden in stack traces. Removes duplicate logic in proxy building.

The main compatibility changes and their rationales are:
1. Modification to the serialization specification: In the "An instance of the class 
is allocated... The contents restored appropriately" section, I propose explicitly 
state that handling of proxies are unspecified as to allow implementation freedom, though 
I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in 
order to control their serialization behavior.
- This is for the existing generated constructor accessor is 
bytecode-based, which cannot refer to hidden classes.
- An alternative is to preserve the behavior, where the serialization 
constructor calls `invokespecial` on the closest serializable superclass' 
no-arg constructor, like in #1830 by @DasBrain.
- My rationale against preservation is such super calls are unsafe and 
should be discouraged in the long term. Calling the existing constructor with a 
dummy argument, as in my implementation, would be more safe.
2. The disappearance of proxies in stack traces.
- Same behavior exists in lambda expressions: For instance, in `((Runnable) () 
-> { throw new Error(); }).run();`, the `run` method, implemented by the 
lambda, will not appear in the stack trace, and isn't too problematic.

A summary of the rest of the changes:
1. Merged the two passes of determining module and package of the proxy into 
one. This reduced a lot of code and allowed anchor class (for hidden class 
creation) selection be done together as well.
2. Exposed internal API for obtaining a full-privileged lookup to the rest of 
`java.base`. This API is intended for implementation of legacy (pre 
`MethodHandles.Lookup`) caller sensitive public APIs so they don't need more 
complex tricks to obtain proper permissions as lookups.
3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): 
passes methods computed by proxy generator as class data to the hidden proxy 
class to reduce generated proxy class size and improve performance.

In addition, since this change is somewhat large, should we keep the old proxy 
generator as well and have it toggled through a command-line flag (like the old 
v49 proxy generator or the old reflection implementation)?

Please feel free to comment or review. This change definitely requires a CSR, 
but I have yet to determine what specifications should be changed.

-

Commit mes

Command line flag to disable finalizers.

[Peter Firmstone]

To securely instrument access controls onto public Java API, we need to 
have the ability to disable finalizers, to prevent finalizer attacks 
from circumventing access controls.


Since finalizers are planned for removal, as soon as finalizers are 
officially deprecated, I propose a command line flag be provided to 
disable jvm calls to finalizer methods.


--
Regards,
 
Peter Firmstone.

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

Thanks for trying David. :)

Regards,

Peter.

On 8/04/2022 7:15 pm, Andrew Dinn wrote:
I'm 100% in agreement with Sean. This proposal leaves the OpenJDK team 
with just as much -- or possibly more -- code to maintain, test and 
design around while making the behaviour under the retained API less 
determinate, less reliable as a security enforcement mechanism and, in 
consequence, even less likely to be used than it is already.


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

On 07/04/2022 20:19, Sean Mullan wrote:

Hi David,

Thanks for the feedback and spending some time on this proposal. Some 
specific comments below.


On 4/5/22 9:52 AM, David Lloyd wrote:

Here at Red Hat there have been serious discussions about the impacts
of security manager removal on our users, and whether there is an
actual value impact, and if so, whether it can be mitigated or
reversed somehow. We are interested in exploring whether we can come
up with a way in which vendors and projects that wish to continue
using SecurityManager (or something like it) would be able to do so,
while still removing the majority of the ongoing maintenance burden
from the OpenJDK project.

Before we make a decision on whether or not we think there is
sufficient justification for working up a formal JEP, we have decided
that the best first step would be to socialize the idea in a more
general form so that we can know whether the upstream OpenJDK team
would even be amenable *at all* to the solution (or something like
it), particularly in light of the observation that previous threads
about retaining SecurityManager in any form have been looked upon in a
fairly negative light.

The primary idea behind this proposal is that, while all of the points
in JEP 411 relating to the lack of what most experts might refer to as
"actual security" are certainly true, the SecurityManager mechanism
itself does nevertheless have some inherent value. The challenge,
then, is to strike a balance between the value provided by retaining
some semblance of the mechanism versus the costs inherent in retaining
it; we would want as much of the former as possible, for as little of
the latter as possible.


With this proposal, as I understand it, the JDK would still be 
responsible for maintaining and preserving essentially all of the 
existing calls to the Security Manager (SM). All new code and APIs 
would still need to be evaluated and determined if permission checks 
were needed as well as making appropriate specification changes to 
note the behavior when an SM is enabled (throwing a 
SecurityException, etc). Any missing checks would need to be treated 
as security issues. And we would still need to test the code and APIs 
to ensure that it worked properly and complied with the API 
specification. This would likely mean implementing and maintaining an 
internal SM implementation in OpenJDK.


The proposal also includes retaining calls to doPrivileged (but later 
potentially replacing them with some other mechanism TBD). The JDK 
source code includes over 1000 calls to doPrivileged. Each of these 
need to be carefully reviewed to ensure that they do not contain 
security issues and any new code needs to be evaluated to see if new 
calls to doPrivileged are necessary.


Retaining doPrivileged (or something similar) means that there can be 
domains of code with different permissions running within the VM, 
which retains much of the complexity of the current SM model.


In this proposal, how privileges are established or propagated is 
implementation-specific. But how could applications or libraries 
depend on the APIs and still have some confidence that the code is 
behaving consistently and securely?


Today, the cost of buying into the SM model is high for libraries and 
applications. Not many third party libraries support the SM and have 
modified their code to perform permission checks and call 
doPrivileged in the right places. If there were pluggable SMs each 
behaving differently, there would likely be less incentive.


Although it sounds beneficial to be able to delegate the SM 
implementation to a 3rd-party, in reality, I think very few people would

take the time to implement it securely, and instead would mostly
leverage its power to do things that aren't at all security related. 
Sure, removing the default SM and Policy implementation reduces the 
complexity a little, but there would still be a fairly significant 
maintenance overhead and an additional drawback that it would make it 
more difficult for applications and libraries to depend on any type 
of consistent behavior.


--Sean



So, here's the idea. It is assumed (for the sake of common
understanding) that as things stand, all of the classes and members
marked as "deprecated for removal" as a part of JEP 411 are intended
to be completely 

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

Hi Sean,

In order to keep our code up to date with Java, we need to replace 
access control functionality.   Current advise is that we will need to 
instrument the Java API, once finalizers have been removed.


The sticking point is about the retention of permission checks, which 
haven't been deprecated by JEP411, OpenJDK does not wish to maintain 
permission checks.


We currently use authentication and access control to prevent parsing 
untrusted data, or loading untrusted code.


This task might be easier if each of the following only have one 
location (or well documented locations) to instrument in the Java 
language public API:


1. Network access
2. File access
3. Property access
4. ClassLoader access / creation.
5. Keystores and credentials.

We also need ways to prevent the jvm from being instrumented, by an 
outside attacker.


Instead of worrying about permission checks and calls to 
SecurityManager, OpenJDK devs just need to ensure they are using these 
standard control points / hooks.


Regards,

Peter.


On 8/04/2022 5:19 am, Sean Mullan wrote:

Hi David,

Thanks for the feedback and spending some time on this proposal. Some 
specific comments below.


On 4/5/22 9:52 AM, David Lloyd wrote:

Here at Red Hat there have been serious discussions about the impacts
of security manager removal on our users, and whether there is an
actual value impact, and if so, whether it can be mitigated or
reversed somehow. We are interested in exploring whether we can come
up with a way in which vendors and projects that wish to continue
using SecurityManager (or something like it) would be able to do so,
while still removing the majority of the ongoing maintenance burden
from the OpenJDK project.

Before we make a decision on whether or not we think there is
sufficient justification for working up a formal JEP, we have decided
that the best first step would be to socialize the idea in a more
general form so that we can know whether the upstream OpenJDK team
would even be amenable *at all* to the solution (or something like
it), particularly in light of the observation that previous threads
about retaining SecurityManager in any form have been looked upon in a
fairly negative light.

The primary idea behind this proposal is that, while all of the points
in JEP 411 relating to the lack of what most experts might refer to as
"actual security" are certainly true, the SecurityManager mechanism
itself does nevertheless have some inherent value. The challenge,
then, is to strike a balance between the value provided by retaining
some semblance of the mechanism versus the costs inherent in retaining
it; we would want as much of the former as possible, for as little of
the latter as possible.


With this proposal, as I understand it, the JDK would still be 
responsible for maintaining and preserving essentially all of the 
existing calls to the Security Manager (SM). All new code and APIs 
would still need to be evaluated and determined if permission checks 
were needed as well as making appropriate specification changes to 
note the behavior when an SM is enabled (throwing a SecurityException, 
etc). Any missing checks would need to be treated as security issues. 
And we would still need to test the code and APIs to ensure that it 
worked properly and complied with the API specification. This would 
likely mean implementing and maintaining an internal SM implementation 
in OpenJDK.


The proposal also includes retaining calls to doPrivileged (but later 
potentially replacing them with some other mechanism TBD). The JDK 
source code includes over 1000 calls to doPrivileged. Each of these 
need to be carefully reviewed to ensure that they do not contain 
security issues and any new code needs to be evaluated to see if new 
calls to doPrivileged are necessary.


Retaining doPrivileged (or something similar) means that there can be 
domains of code with different permissions running within the VM, 
which retains much of the complexity of the current SM model.


In this proposal, how privileges are established or propagated is 
implementation-specific. But how could applications or libraries 
depend on the APIs and still have some confidence that the code is 
behaving consistently and securely?


Today, the cost of buying into the SM model is high for libraries and 
applications. Not many third party libraries support the SM and have 
modified their code to perform permission checks and call doPrivileged 
in the right places. If there were pluggable SMs each behaving 
differently, there would likely be less incentive.


Although it sounds beneficial to be able to delegate the SM 
implementation to a 3rd-party, in reality, I think very few people would

take the time to implement it securely, and instead would mostly
leverage its power to do things that aren't at all security related. 
Sure, removing the default SM and Policy implementation reduces the 
complexity a little, but there would still be a fairly significant 

Re: RFR: 8284490: Remove finalizer method in java.security.jgss

[Peter Firmstone]

Looks good to me, removes credentials when phantom reachable, doesn't do 
anything that would prevent it from becoming reachable.  You removed the 
GNSSException that wasn't thrown.


Regards,

Peter.

On 7/04/2022 2:17 pm, Xue-Lei Andrew Fan wrote:

Please review the update to remove finalizer method in the java.security.jgss 
module. It is one of the efforts to clean up the use of finalizer method in JDK.

-

Commit messages:
  - 8284490: Remove finalizer method in java.security.jgss

Changes: https://git.openjdk.java.net/jdk/pull/8136/files
  Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8136=00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8284490
   Stats: 40 lines in 3 files changed: 20 ins; 15 del; 5 mod
   Patch: https://git.openjdk.java.net/jdk/pull/8136.diff
   Fetch: git fetch https://git.openjdk.java.net/jdk pull/8136/head:pull/8136

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

Re: A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

Thanks David,

I'd certainly support such a proposal and encourage OpenJDK to consider 
exploring it.


Perhaps also consider; no privileges should be granted unless a 
privileged call is made, this simplifies the the stack walk, such that 
it's only required when a privileged call is made.


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


Something that bothered me about SocketPermission was that it didn't 
allow granting permission to subnets, or ranges of IP addresses.


It always bothered me that data parsing isn't controlled with permissions.

For data parsing the remote authenticated subject represents the source 
of the data, if the data source cannot be authenticated, then data 
cannot be parsed.   Of  course when parsing is done it needs to be 
validated, but authentication goes a long way to filtering out potential 
attack vectors.


--
Regards,
 
Peter


On 5/04/2022 11:52 pm, David Lloyd wrote:

Here at Red Hat there have been serious discussions about the impacts
of security manager removal on our users, and whether there is an
actual value impact, and if so, whether it can be mitigated or
reversed somehow. We are interested in exploring whether we can come
up with a way in which vendors and projects that wish to continue
using SecurityManager (or something like it) would be able to do so,
while still removing the majority of the ongoing maintenance burden
from the OpenJDK project.

Before we make a decision on whether or not we think there is
sufficient justification for working up a formal JEP, we have decided
that the best first step would be to socialize the idea in a more
general form so that we can know whether the upstream OpenJDK team
would even be amenable *at all* to the solution (or something like
it), particularly in light of the observation that previous threads
about retaining SecurityManager in any form have been looked upon in a
fairly negative light.

The primary idea behind this proposal is that, while all of the points
in JEP 411 relating to the lack of what most experts might refer to as
"actual security" are certainly true, the SecurityManager mechanism
itself does nevertheless have some inherent value. The challenge,
then, is to strike a balance between the value provided by retaining
some semblance of the mechanism versus the costs inherent in retaining
it; we would want as much of the former as possible, for as little of
the latter as possible.

So, here's the idea. It is assumed (for the sake of common
understanding) that as things stand, all of the classes and members
marked as "deprecated for removal" as a part of JEP 411 are intended
to be completely removed without replacement at the end of the term of
deprecation.  The proposals here are based on this assumption.

The center of this proposal is that, at the end of the term of
deprecation, all of the deprecated classes, members, and behavior are
still removed (including, and especially, AccessController and Policy
and related classes) /except/ as mentioned here:

  * Rather than completely removing SecurityManager,
  * The SecurityManager class becomes abstract and non-deprecated,
with all of its methods being removed, except as follows
  * SecurityManager.getSecurityContext() becomes abstract (this is
the one that returns Object, *not* the stack walking one)
  * SecurityManager.checkPermission() (both of them) become abstract
  * Rather than removing the SecurityManager-related methods from System,
  * System.getSecurityManager() is retained and de-deprecated
  * [Optional] System.setSecurityManager() is retained and
de-deprecated (we would want to explore whether it is feasible to
replace this (and the system property lookup mechanism) using
ServiceLoader, if bootstrap allows it)
  * [Optional] Rather than /immediately/ removing all of AccessController,
  * Retain its deprecation-for-removal status
  * Retain only doPrivileged(PrivilegedAction) and
doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no
JVM semantics other than being present on the call stack like any
method) since they are pervasively used, to allow frameworks time to
transition to (for example) a third-party alternative.

The burden of permission verification would lie completely with the
security manager implementation.  The JDK would not have a
'SecurityManager' implementation of any kind, outside of the internal
test suite.

The other part of this proposal can come in one of two possible flavors.

### Option 1: Authorization interfaces

Each point in the JDK where there presently is a permission check is
classified into an authorization category of related operations. An
interface is introduced for each category which contains the methods
encapsulating the relevant check, in a package that is deemed most
appropriate for that particular grouping.  For example, there might be
a 'SocketAuthorization' 

Re: JEP 411: sandboxing use case

[Peter Firmstone]

Hi Olivier,

After JEP 421 (deprecation of finalizers) and a JEP is assigned to 
removal of finalizers, it will be possible to instrument java methods 
and intercept their calls.   While finalizers exist, instrumenting 
constructors would allow finalizer attacks to circumvent the permission 
check.


OpenJDK has no intention of developing a new authorization framework / 
api.   Until such time as finalizers are removed, SM is the only option 
currently available for authorization within the JVM.


You can make a JVM process less privileged, or sandbox a JVM within a 
VM, but if the JVM (without SM) is able to generate a students result, 
then student code will also be able to.   I did consider briefly the 
possibility of using two processes, one for the student code (isolated 
in an unprivileged process or VM) and one for the grading code, but I 
think the grading jvm would be susceptible to some form of injection 
attack, as it has to parse untrusted data.


Be sure to disable Serialization, as SM doesn't prevent its use and any 
other forms of potentially dangerous data parsing.


-Djdk.serialFilter=!*,\

-Dcom.sun.jndi.ldap.object.trustSerialData=false,\

Regards,

Peter.


On 12/01/2022 7:49 am, Sean Mullan wrote:



On 1/10/22 9:22 AM, Olivier Cailloux wrote:

Dear list,

I would like to share my use case for currently using the security
manager mechanism (SM) in my software. Now that JEP 411 is there, any
advice about any currently existing solution for replacement would be
welcome, if this is already possible; alternatively, I hope that a
replacement for these needs will be available soon.


You may want to consider container technologies. This is mentioned in 
the last paragraph of the Motivation section of JEP 411.


--Sean



My software grades student work. It download their code from GitHub,
compiles it, runs it, and observe the results (similar to running JUnit
tests, but on pluggable code). Their code is then graded automatically
depending on the expected versus actual results.

I currently use SM to prevent student code to alter the system on which
the code runs or have external impact. I don’t want them to read files
or send network requests (they usually do not need to do anything like
this for the exercices assigned to them). I currently use a simple “no
priviledged calls at all” configuration, where everything that can be
forbidden by SM is forbidden for their code, as they only need to be
able to deal with their own objects and classes from the JDK that
operate “taint-free” (as Chapman Flak puts it), such as classical List
or Set structures.

Though I do not currently need such more advanced feature, I considered
as a good bonus that SM allowed me, if I wanted to, to give exercices
that also deal with file writing (through telling SM that their code
can access a restricted set of files). If any replacement solution
could also allow this kind of flexibility, that would be nice.

I am aware that their code could implement a denial of service; I am
okay to live with this risk as any resulting damage would be low (worst
case, just restart the computer). But I’d like to reduce the risk that
their code would read or modify files or other aspects of the system it
is running on, for example, as the resulting damage could be much
higher (such as: alter the way the system works so that the grading of
other students, graded next, would be modified; read personal files
from the account that is running the grading software and posting their
content on the internet; inadvertently delete files on the host
system…)

I implement code isolation so that one student code does not see or
interact with the code of other students classical using class loader
mechanisms, for which JEP 411 does not create problems. But I ignore
how to prevent file writing, socket opening, or similar stuff, using
other means than SM.

My needs resemble (but are not identical to) the ones exposed by
Chapman Flack in “JEP 411: Missing use-case: user functions in an
RDBMS”, https://marc.info/?m=162216583127042. I share the concern of
this poster (https://marc.info/?m=162221303911911) that it currently
seems that I’d have to come up with various, specialized mechanisms to
prevent various kinds of operations (file system access, socket
access, …), which seems inelegant and error-prone.

Even after reading the insightful article of Ron Pressler, Shallow Java
Sandboxes
(https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/), 


it is unclear to me whether I can get rid of SecurityManager with
existing Java 17 technology. Any advice would be welcome. If not
possible, please consider this use case when thinking about further
progress in replacing the security related APIs. (I am quite worried by
the wording of JEP 411 Future Work not mentioning this kind of
sandboxing need.)

Olivier

Re: JDK17 - Possible TLS issue.

[Peter Firmstone]

Thanks Jamil,

You'll need to use JDK 8 for building / compiling,

Additional to the build instructions, to test the specific test in question:

Create a build.properties file in the project root directory (same 
directory as README.md), containing the following entries:


   jsk.home=absolute path to JGDMS project directory.
   
run.tests=org/apache/river/test/spec/lookupservice/test_set02/LookupNegMatches.td

These two files allow you to manipulate JVM arguments and logging:

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/qa/resources/qaDefaults.properties

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/resources/qa1.logging

JGDMS runs with a SecurityManager enabled by default, I haven't yet 
tested it without SM.


In the event that you experience an AccessControlException / 
SecurityException, insert the following two properties to 
qaDefaults.properties, at line 426:


-Djava.security.manager=org.apache.river.tool.SecurityPolicyWriter,\
-DSecurityPolicyWriter.path.properties=${qa.home}/harness/policy/securitypolicywriterpath.properties,\

These will update policy files with any missing permissions the next 
time you run the test (you may need to run it on JDK16), then you should 
remove these two options, as the policy files will have all necessary 
permissions.


I did manage to capture one passing run on JDK17, I haven't been able to 
reproduce it, but it suggests the failure might be related to timing, 
locking or gc:


https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-security-debug-fine-logging-tls-handshake.txt

Regards,

Peter.

On 12/08/2021 5:32 am, Jamil Nimeh wrote:

Hi Peter,

I've captured the issue in 
https://bugs.openjdk.java.net/browse/JDK-8272340.  The synopsis is a 
bit vague right now as I'm going through the logs.  I'll revise it 
once I have a little more info.  I was also looking at the JGDMS 
project just to see how easy it would be for me to replicate the 
specific tests that exhibit the failure.  I may contact you directly 
for a bit more info.  The instructions on the JGDMS page look pretty 
straightforward, so hopefully that won't take long to replicate.


Thanks,

--Jamil

On 8/11/2021 3:12 AM, Peter Firmstone wrote:

谢谢johnsjiang(江莎)，

I set the property:

-Djdk.tls.acknowledgeCloseNotify=true.

Unfortunately the test is still failing on JDK17, although the output 
has changed and acknowledges the duplex close, so it appears 
something else is causing the connection to close early. 
Interestingly, there is a WARNING that the socket didn't close, 
followed by an ERROR, then FATAL(UNEXPECTED MESSAGE).


致以诚挚的问候Peter.

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug-ack-close-notify-true.txt 



 [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) 
ConnectionManager.Reaper|2021-08-11 19:41:49.598 
AEST|SSLSocketImpl.java:572|duplex close of SSLSocket
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert 
message (

 [java] ActSys-err: "Alert": {
 [java] ActSys-err:   "level"  : "warning",
 [java] ActSys-err:   "description": "user_canceled"
 [java] ActSys-err: }
 [java] ActSys-err: )
 [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) 
ConnectionManager.Reaper|2021-08-11 19:41:49.599 
AEST|SSLSocketImpl.java:1775|close the SSL connection (passive)
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert 
message (

 [java] ActSys-err: "Alert": {
 [java] ActSys-err:   "level"  : "warning",
 [java] ActSys-err:   "description": "close_notify"
 [java] ActSys-err: }
 [java] ActSys-err: )
 [java] ActSys-err: javax.net.ssl|ALL|A2|(JSK) mux 
writer|2021-08-11 19:41:49.599 AEST|SSLSocketImpl.java:1324|Closing 
output stream
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex 
close of SSLSocket
 [java] ActSys-err: javax.net.ssl|ALL|C2|(JSK) mux 
writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1324|Closing 
output stream
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the 
SSL connection (passive)
 [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux 
writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex 
close of SSLSocket
 [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux 
writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the 
SSL connection (passive)
 [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux 
reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1129|Closing 
input stream
 [java] ActSys-err: javax.net.ssl|WARNING|C2|(JSK) mux 
writer|2021-08-11 19:41:49.602 AEST|SSLSocket

Re: JDK17 - Possible TLS issue.

[Peter Firmstone]

b\phoenix-init-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-platform-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\jgdms-lib-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-lib-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-jeri-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-group-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\phoenix-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-common-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-parameters-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-url-integrity-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bcprov-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bctls-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\security-policy-debug-3.1.1-SNAPSHOT.jar, 
org.apache.river.phoenix.init.ActivationGroupInit]
 [java] ActSys-err: javax.net.ssl|WARNING|F1|(JSK) mux request 
dispatch|2021-08-11 19:42:32.033 
AEST|ServerNameExtension.java:266|Unable to indicate server name
 [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request 
dispatch|2021-08-11 19:42:32.033 AEST|SSLExtensions.java:272|Ignore, 
context unavailable extension: server_name
 [java] ActSys-err: javax.net.ssl|INFO|F1|(JSK) mux request 
dispatch|2021-08-11 19:42:32.034 AEST|AlpnExtension.java:182|No 
available application protocols
 [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request 
dispatch|2021-08-11 19:42:32.034 AEST|SSLExtensions.java:272|Ignore, 
context unavailable extension: application_layer_protocol_negotiation
 [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request 
dispatch|2021-08-11 19:42:32.034 
AEST|SessionTicketExtension.java:408|Stateless resumption supported
 [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request 
dispatch|2021-08-11 19:42:32.035 AEST|SSLExtensions.java:272|Ignore, 
context unavailable extension: cookie
 [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request 
dispatch|2021-08-11 19:42:32.041 AEST|PreSharedKeyExtension.java:662|No 
session to resume.
 [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request 
dispatch|2021-08-11 19:42:32.041 AEST|SSLExtensions.java:272|Ignore, 
context unavailable extension: pre_shared_key
 [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request 
dispatch|2021-08-11 19:42:32.044 AEST|ClientHello.java:652|Produced 
ClientHello handsha




On 11/08/2021 7:22 pm, johnsjiang(江莎) wrote:

+ security-dev

Hi Peter,
It looks both of file 1 and 5 contain that close_notify warning alert.
This point may be related to JDK-8208526: TLS 1.3 half-close and 
synchronization issues [1].

[1] https://bugs.openjdk.java.net/browse/JDK-8208526

Best regards,
John Jiang

At 2021/8/11 PM 4:14, Peter Firmstone wrote:

I'm testing on JDK17, having some issues communicating using TLS between
processes.

With TLS disabled, the test passes on JDK17.

The test passes using TLS on JDK 16 and earlier JDK versions.

I've enabled TLS handshake debug on the output

  1. 
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16-tls-handshake-debug.txt
  2. 
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16.txt
  3. 
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-disabled.txt
  4. 
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-tls-handshake-debug.txt
  5. 
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug2.txt

There are 5 JVM instances created during this integration test and these
JVM's are communicating using network connections.  I have checked that
all JVM processes are running, it seems to be a communication issue.

Using diff to compare fil

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

[Peter Firmstone]

I'm grateful for everyone's ideas and feedback, in the coming days & 
weeks I'll put together some documentation to summarize and put some 
time into some proposals, I have a lot of experience with the SM 
infrastructure and its inner workings, having had to work around it's 
pitfalls.


Watch this space, I'll post a link when ready.

Regards,

Peter.


On 5/08/2021 7:27 am, Sean Mullan wrote:


On 8/3/21 8:10 PM, Peter Firmstone wrote:

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.


This is a case similar to AccessController.doPrivileged where we could 
potentially keep the existing APIs in place for a longer time period 
until such time the compatibility risk is low and 
applications/libraries have had ample time to convert to the new APIs. 
See the paragraph about degrading APIs in JEP 411: 
https://openjdk.java.net/jeps/411#Description


As an interim step, the existing APIs could be adapted such that they 
simply call the new APIs which will likely use a different mechanism 
to transfer the Subject across API boundaries (ThreadLocals or 
eventually Scope Locals, when they arrive).



   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?


I don't know, it was mostly just an idea I am throwing out based on 
your #2 statement above. I don't have the time to fully understand 
your model, but more simply if you know who is authorized and who 
isn't, it seems like you would have direct control over what the users 
are authorized to do and instead of relying on the Security Manager to 
catch operations already in motion, you could prevent them before they 
even occur. This seemed like one of those cases.


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.


It's a two way street, I'm currently penetration testing OpenJDK dev's
to discover their pain points with SM architecture, as they haven't
documented them in JEP411.  When I am sure I have discovered your pain
points, I plan to document a proposal. There's no point writing
something up that address the wrong pain points.

On that topic, I think for historical purposes, JEP 411's wording could
more accurately reflect the experiences of developers who overcame the
shortcomings that beginners experience with SM.   JEP 411 does well to
document beginners experiences when first attempting to use SM, however
I think this unfairly penalizes the original authors, history should
look more kindly on their achievements.  SM is a great achievement that
stood the test of time for over 20 years, and no one else has succeeded
at this task, it's not perfect, but it works well for those who are
using it to it's full potential.  It's association with Applets and
their use of ClassLoaders as a weak form of isolation, and the resulting
permission sprawl that eventuated as band-aids to each vulnerability, is
unfortunate.


I don't disagree that the SecurityManager was a significant 
achievement. B

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

[Peter Firmstone]

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.

[Peter Firmstone]

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.

[Peter Firmstone]

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 con

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

[Peter Firmstone]

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.

[Peter Firmstone]

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.

[Peter Firmstone]

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.

[Peter Firmstone]

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.

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
   <https://bugs.openjdk.java.net/browse/JDK-8267108> 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
   <https://openjdk.java.net/jeps/411#subject-doas>).

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 so

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

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 repl

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.

[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
   <https://mail.openjdk.java.net/pipermail/vuln-announce/2019-July/02.html>

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.

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

[Peter Firmstone]

t majority of Java users, low (what’s affected most users is 
reliance on non-spec-compliant
libraries, and the need to import the external artefacts for EE). The most 
impactful change has probably
been the removal of some client deployment technologies from the Oracle JDK, 
but as far as OpenJDK is
concerned, the affected areas have been CORBA, pack200, Nashorn, and now the 
process to remove SM is
starting. The number of people using any one of these is low, and the number of 
those who need to work
hard for alternatives is very low. I think that advance warning, and then 
support offerings by multiple
vendors for those who have not managed to migrate in the advance warning period 
is reasonable; always
offering ways to support removed technologies together with new features in 
current releases with the
same code base is not. When compared with other ecosystems, Java’s strategy is 
exceptionally tolerant
of those that prefer slow change.

- Property-based testing is wonderful, I wish more people would use it, and I 
hope to see it used in
the JDK as well. Java has several PBT tools, but I believe the most popular one 
these days is
https://jqwik.net/. As long as you’re still with Java, give it a try.

— Ron


On 31 Jul 2021, at 04:04, Peter Firmstone  wrote:

The current JEP 411 plan of action, if left unchanged, will leave developers 
who adopted the SM architecture as an authorization layer unable to upgrade to 
later versions of Java, until finalizers and the finalizer attack defensive 
methods in constructors are removed.  JEP 411 has the potential to cause 
significant disruption for a small proportion of Java developers, but doesn't 
have to if managed appropriately.

The blocker is the ability to implement guard checks using Agents on public 
API, due to finalizer attack defensive private static methods in constructors.

Allan has advised when finalizers are removed, it will be practical to use 
Agents to instrument public API to implement an authorization layer, this is 
try, so can it be coordinated with JEP 411 et al?

Furthermore, as developers must support multiple Java releases, I propose the 
following amendments, to ease difficulties of multiple release support (with 
multi release jars):

* AccessController, AccessControlContext, DomainCombiner and related
   Subject and Executors methods, remain until Java 8 is EOL in 2030.
   Also consider un-deprecation of these methods, as their removal
   causes shotgun surgery (used in 1000's of locations in my software
   alone) and they are required for preservation of Subject, used for
   obtaining TLS and Kerberos connection credentials on all existing
   versions of Java.
* AccessControlContext - remove inherited thread context, replace it
   with an unprivileged ProtectionDomain, such that doPrivileged
   methods are required for authorization checks and only the current
   thread stack needs to be walked when checks occur, and stack walks
   aren't unnecessarily performed when creating new threads.   This is
   compatible with Loom, update loom to allow the use of
   AccessControlContext to be used, to establish TLS and Kerberos
   connections.  Loom will be very useful for network connections,
   especially long latency connections over the internet, which are
   typically secured using TLS.   This removes the problem of viral
   checks, and Executor task privilege escalation.
* Modules that are mapped to the boot loader should get a unique PD
   that includes a useful code source rather than using a "shared" PD,
   this allows us to reduce the privileged footprint of the Java
   platform libraries, to allow privileges to be granted to users, not
   code, or users and code.  This is useful to limit data parsing
   privileges to authenticated users on servers (a practise that should
   be more widely encouraged).
* Remove finalizers, and defensive methods in constructors where
   permissions check points occur as these cause problems for Agents,
   prior to removal of SecurityManager.
* Deprecate for removal Permission implementations, then remove them
   in a following release.
* Remove SecurityManager.

This allows a forward migration path for poor sod's like myself who are 
currently using SM infrastructure as an authorization layer, and to establish 
TLS conenctions, this or at least some sort of compromise is far preferable to 
the thermonuclear option currently planned.

What I would like OpenJDK to consider, is to allow developers like myself to 
continue to stay current with Java, by coordinating the removal of finalizers 
and defensive methods in constructors, with JEP 411, so we have a workable 
future migration path. Without these considerations, options are; go back to 
Java 8, and plan to redevelop existing software, if forced to do so, Java is 
unlikely to be on the list for redevelopment, simply because development costs 
are lower in newer languages, such as automated unit 
tests,https://hackage.haskell.org/package

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

[Peter Firmstone]

I'm potentially watching many years of development efforts burn, due to 
JEP 411 and trying to find a way to save it, I don't refer to it as 
fun.  Frustrating, infuriating, irritating, anger, that would more 
accurately describe the emotions current circumstances create.


I'll be focusing only on the following in Java's public API's:

1. Network.
2. File system access.
3. ClassLoading.
4. Properties.

The most important task is to prevent class loading from unauthenticated 
sources.


This is intended to sure up perimeter defenses and constrain trusted 
third parties in our software, these would be wide open if we just 
switched off SM.


I'm following all guidance provided by OpenJDK in this instance.

I will wait for finalizers to be removed, before instrumenting any 
constructors that have finalizer attack defenses.  Hopefully OpenJDK 
will chose to remove finalizers soon, prior to removal of SM.


Regards,

Peter.



On 31/07/2021 5:35 pm, Alan Bateman wrote:

On 31/07/2021 04:04, Peter Firmstone wrote:


Allan has advised when finalizers are removed, it will be practical 
to use Agents to instrument public API to implement an authorization 
layer, this is try, so can it be coordinated with JEP 411 et al?


Our exchange was about instrumenting constructors that specify SM 
permission checks and where the classes that define these constructors 
have been hardened to thwart finalizer attacks. It wasn't a comment on 
the bigger question on how practical it is to use instrumented the 
entire JDK. Once you get further on then I assume a big challenge will 
be with APIs that separate the interface and implementation (think 
factory methods, APIs that define service provider interfaces ...). 
Here I expect you will want to instrument the implementation classes. 
Going deeper, you may find places where the SM check isn't on method 
entry but instead after defensive copying of mutable parameters or 
after acquiring a lock that prevents mutation while do a security 
sensitive operations. So non-trivial but a fun approach to explore. If 
you have the cycles then pick a version and try it. That will give you 
a sense on how much effort may be required to keep up and be confident 
that every interesting code path is covered.


-Alan

JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

The current JEP 411 plan of action, if left unchanged, will leave 
developers who adopted the SM architecture as an authorization layer 
unable to upgrade to later versions of Java, until finalizers and the 
finalizer attack defensive methods in constructors are removed.  JEP 411 
has the potential to cause significant disruption for a small proportion 
of Java developers, but doesn't have to if managed appropriately.


The blocker is the ability to implement guard checks using Agents on 
public API, due to finalizer attack defensive private static methods in 
constructors.


Allan has advised when finalizers are removed, it will be practical to 
use Agents to instrument public API to implement an authorization layer, 
this is try, so can it be coordinated with JEP 411 et al?


Furthermore, as developers must support multiple Java releases, I 
propose the following amendments, to ease difficulties of multiple 
release support (with multi release jars):


 * AccessController, AccessControlContext, DomainCombiner and related
   Subject and Executors methods, remain until Java 8 is EOL in 2030. 
   Also consider un-deprecation of these methods, as their removal
   causes shotgun surgery (used in 1000's of locations in my software
   alone) and they are required for preservation of Subject, used for
   obtaining TLS and Kerberos connection credentials on all existing
   versions of Java.
 * AccessControlContext - remove inherited thread context, replace it
   with an unprivileged ProtectionDomain, such that doPrivileged
   methods are required for authorization checks and only the current
   thread stack needs to be walked when checks occur, and stack walks
   aren't unnecessarily performed when creating new threads.   This is
   compatible with Loom, update loom to allow the use of
   AccessControlContext to be used, to establish TLS and Kerberos
   connections.  Loom will be very useful for network connections,
   especially long latency connections over the internet, which are
   typically secured using TLS.   This removes the problem of viral
   checks, and Executor task privilege escalation.
 * Modules that are mapped to the boot loader should get a unique PD
   that includes a useful code source rather than using a "shared" PD,
   this allows us to reduce the privileged footprint of the Java
   platform libraries, to allow privileges to be granted to users, not
   code, or users and code.  This is useful to limit data parsing
   privileges to authenticated users on servers (a practise that should
   be more widely encouraged).
 * Remove finalizers, and defensive methods in constructors where
   permissions check points occur as these cause problems for Agents,
   prior to removal of SecurityManager.
 * Deprecate for removal Permission implementations, then remove them
   in a following release.
 * Remove SecurityManager.

This allows a forward migration path for poor sod's like myself who are 
currently using SM infrastructure as an authorization layer, and to 
establish TLS conenctions, this or at least some sort of compromise is 
far preferable to the thermonuclear option currently planned.


What I would like OpenJDK to consider, is to allow developers like 
myself to continue to stay current with Java, by coordinating the 
removal of finalizers and defensive methods in constructors, with JEP 
411, so we have a workable future migration path. Without these 
considerations, options are; go back to Java 8, and plan to redevelop 
existing software, if forced to do so, Java is unlikely to be on the 
list for redevelopment, simply because development costs are lower in 
newer languages, such as automated unit tests, 
https://hackage.haskell.org/package/QuickCheck, no need to worry about 
null pointers and less boilerplate.


Don't get me wrong, I like Java and have many years experience with it, 
but I have to be pragmatic, it won't just be me, many other developers, 
when Java 8 is EOL, will work for companies stuck on that platform, 
simply due to the number of changes required, because they haven't kept 
up (eg budgets) with the current release cadence and pace of 
development, will be looking at redevelopment and replacement instead of 
migration.   Clearly the current pace of development is a good thing for 
Java, but the overall strategy could be tweaked a little, to ensure 
migration doesn't become insurmountable.  A healthy and vibrant Java 
community is essential for the survival of Java, Java has already shed 
phone and client markets, lets not shed too many more.


Thanks,

 
Peter

Re: How to remove the SecurityManager

[Peter Firmstone]

Appended inline below.

On 29/07/2021 11:20 am, Peter Firmstone wrote:


The intent of the following process is to perform a targeted audit, 
which allows inspection of small parts of the code identified by these 
steps.


On 28/07/2021 9:12 am, Peter Firmstone wrote:


Our process for establishing whether third party libraries are 
trusted before we use them:


 1. Build dependency check using Owasp
https://owasp.org/www-project-dependency-check/ Reject any
dependencies that fail, see
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml line
87 for an example of a disabled module due to a vulnerability in
a dependency, the module will only be re-enabled if the
vulnerability is fixed.
 2. Static analysis using SpotBugs, then review identified bugs,
review source code if available.  Reject if security bugs are
present, or fix / patch.
 3. Profiling of permission access checks using:

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java
 4. Reviewing generated policy files, using grep, this example was
generated from over 2000 tests:

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new
 5. Remove any permission from the policy file you don't want to
grant to third party code, if safe to do so, eg usage statistics
reporting.

In the construction industry, a similar approach is used by structural 
engineers and weld inspectors, when inspecting welds for defects, 
using Ultrasonic, X-Ray or visual inspection, weld defects in 
structures have the potential to cause catastrophic failure and 
multiple fatalities, likely worse consequences than a bug in Java, so 
engineers identify critical areas  for inspectors to target with 100% 
coverage, perhaps by UT or X-Ray, to inspect the weld internally, then 
the structural engineer will nominate to inspect 10% of other areas 
with UT, with 100% visual inspection, for example, if defects are 
found, then they will increase UT inspection coverage, welds need to 
be gouged out and re-welded, until the inspector is satisfied with 
quality.


A targeted code audit process will also identify code quality, if 
there are many bugs, don't use it, even if these aren't security bugs.


This can hardly be compared with the approach used for running Applets 
in a sandbox that may have malicious intent, in that case no auditing 
has been performed at all.


This use case of SecurityManager recognizes shortcomings of Java 
platform security.   Sandboxing was a marketing term used for Applets, 
I don't know the origin of the term sandbox when used for computer 
security, but whenever there is a sandbox, there is a risk of escape, 
and simplicity is thy friend, it should be left to cyber security 
professionals.


If you removed applets, then there is no use case for a Sandbox, so 
why remove SecurityManager?


Come on honestly, JEP 411 is confirmation biased, is overly focused on 
sandboxing and therefore not factual or relevant, I've provided 
sufficient evidence contrary to it's claims.   It needs to take the 
ability to migrate code into account as well as use cases other than 
sandboxing.


We use SM to prevent loading of untrusted (unaudited) code and 
untrusted (unauthenticated) data, but we don't use it as a sandbox to 
attempt to encapsulate malicious code and malicious users, we use it 
for authorization decisions, for external users and services, this 
could also be applied to Web Services, not just Jini services, these 
authorization decisions prevent loading untrusted code and parsing 
untrusted data.


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";

};

Rather than throwing developers who use SM under the bus, we could be 
given a migration path:


 1. Review and reduce the number of permissions focused *only* on
authorization use cases.   Eg: Give Properties useful for
authorization their own guarded area in the Property map?   I
mean, why are we guarding java.util.PropertyPermission
"java.specification.version", "read" and many others like it?  
Fix SocketPermission, add netmask wild cards, use RFC3986
normalization, stop using DNS.  Ever heard of DNS spoofing?
 2. What about parsing of data?  Such as XML and Java Serialization,
among others, this should have a permission check, that when
granted to users, ensu

Re: How to remove the SecurityManager

[Peter Firmstone]

The intent of the following process is to perform a targeted audit, 
which allows inspection of small parts of the code identified by these 
steps.


On 28/07/2021 9:12 am, Peter Firmstone wrote:


Our process for establishing whether third party libraries are trusted 
before we use them:


 1. Build dependency check using Owasp
https://owasp.org/www-project-dependency-check/ Reject any
dependencies that fail, see
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml line
87 for an example of a disabled module due to a vulnerability in a
dependency, the module will only be re-enabled if the
vulnerability is fixed.
 2. Static analysis using SpotBugs, then review identified bugs,
review source code if available.  Reject if security bugs are
present, or fix / patch.
 3. Profiling of permission access checks using:

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java
 4. Reviewing generated policy files, using grep, this example was
generated from over 2000 tests:

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new
 5. Remove any permission from the policy file you don't want to grant
to third party code, if safe to do so, eg usage statistics reporting.

In the construction industry, a similar approach is used by structural 
engineers and weld inspectors, when inspecting welds for defects, using 
Ultrasonic, X-Ray or visual inspection, weld defects in structures have 
the potential to cause catastrophic failure and multiple fatalities, 
likely worse consequences than a bug in Java, so engineers identify 
critical areas  for inspectors to target with 100% coverage, perhaps by 
UT or X-Ray, to inspect the weld internally, then the structural 
engineer will nominate to inspect 10% of other areas with UT, with 100% 
visual inspection, for example, if defects are found, then they will 
increase UT inspection coverage, welds need to be gouged out and 
re-welded, until the inspector is satisfied with quality.


A targeted code audit process will also identify code quality, if there 
are many bugs, don't use it, even if these aren't security bugs.


This can hardly be compared with the approach used for running Applets 
in a sandbox that may have malicious intent, in that case no auditing 
has been performed at all.


This use case of SecurityManager recognizes shortcomings of Java 
platform security.   Sandboxing was a marketing term used for Applets, I 
don't know the origin of the term sandbox when used for computer 
security, but whenever there is a sandbox, there is a risk of escape, 
and simplicity is thy friend, it should be left to cyber security 
professionals.


If you removed applets, then there is no use case for a Sandbox, so why 
remove SecurityManager?


Come on honestly, JEP 411 is confirmation biased, is overly focused on 
sandboxing and therefore not factual or relevant, I've provided 
sufficient evidence contrary to it's claims.   It needs to take the 
ability to migrate code into account as well as use cases other than 
sandboxing.


We use SM to prevent loading of untrusted (unaudited) code and untrusted 
(unauthenticated) data, but we don't use it as a sandbox to attempt to 
encapsulate malicious code and malicious users, we use it for 
authorization decisions, for external users and services, this could 
also be applied to Web Services, not just Jini services, these 
authorization decisions prevent loading untrusted code and parsing 
untrusted data.


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";

};

Rather than throwing developers who use SM under the bus, we could be 
given a migration path:


1. Review and reduce the number of permissions focused *only* on
   authorization use cases.   Eg: Give Properties useful for
   authorization their own guarded area in the Property map?   I mean,
   why are we guarding java.util.PropertyPermission
   "java.specification.version", "read" and many others like it? Fix
   SocketPermission, add netmask wild cards, use RFC3986 normalization,
   stop using DNS.  Ever heard of DNS spoofing?
2. What about parsing of data?  Such as XML and Java Serialization,
   among others, this should have a permission check, that when granted
   to users, ensures the data source has been authenticated.   This is
   a server application, not 

Re: How to remove the SecurityManager

[Peter Firmstone]

Thanks Remi, I'm a user of ASM also, for a long time, since 2007, it's a 
very performant library.


Yes, we could replace the policy audit with another tool, but it's 
academic, the remaining code cannot be upgraded.


For now the policy tools informs me of reflection access, I don't need 
to blacklist it if I read the code and it's doing something harmless, 
eg. it might be calling public methods, to support multiple versions of 
java.


I looked at Agents to replace permission checks, it requires 
modification of private methods, it's bad practice, we've removed all 
code that accessed private implementation or state, we only use public API.


It's not just a simple case of instrumenting public API's, many 
permissions defend constructors, and constructors contain private static 
methods to defend against finalizer attacks.   While I could defend 
public methods, methods are called far more often than constructors, it 
would have an unacceptable impact on performance.  Years will pass 
before finalizers are removed and constructors are simplified so they 
can be instrumented.


It's not viable to re-implement an authorization layer as an external 
library for Java.


Right now SM only has a less than 3% impact on performance and doesn't 
affect scalability, how can I justify replacing it, for what new 
feature?   I don't run untrusted code, it works reliably for the 
authorization based access controls that I require and provides access 
to subject credentials for authentication of secure connections.


Performance profiling of SM running with stateless TLS sockets
<https://imgur.com/VcSwffC>

https://imgur.com/VcSwffC

https://imgur.com/VcSwffC

https://imgur.com/VcSwffC

I think Haskell has better type safety than Java, it handles Null with 
Maybe, it's good for parsing data, it appears to have made few 
compromises in its design, but I'm not saying that from experience. I 
think if I was looking for something to run untrusted code, it would be 
as source code that I parsed, then compiled, perhaps a subset of Haskell 
parsed as source code, if I used it for that, then it's audited by 
parsing and the compiler. I guess something similar could be done with 
ASM and bytecode, but it's not my goal to run untrusted code, I'll leave 
the sandbox for the developers cat to bury applets.


Regards,

Peter.


On 28/07/2021 7:41 pm, fo...@univ-mlv.fr wrote:





*From: *"Peter Firmstone" 
*To: *"Remi Forax" , "Alan Bateman"

*Cc: *"jdk-dev" , "security-dev"

*Sent: *Wednesday, July 28, 2021 1:12:32 AM
*Subject: *Re: How to remove the SecurityManager

Thanks Remi,

Sand-boxing is a bad idea, we are in agreement, it's not something
we do, personally I'm taking an interest in safer languages, eg
Haskell on secure platforms, eg OpenBSD on Sparc64 *.

Perhaps JEP 411 is simply a reflection on the evolution of
languages.  Java was safer than C and C++ so replaced these,
something safer again will replace Java.


All mainstream languages have a way to access to raw pointers to be 
able to call C functions,

here is the one in Haskell
https://hackage.haskell.org/package/base-4.5.0.0/docs/Foreign-Storable.html


I think people are getting our primary use case, authorization,
confused with sandboxing (not on our use case list).  OpenJDK
developers provided a Sandbox example, I just wanted to
communicate that I didn't think it was a practical defense against
exploits, nor applicable to our use case:

https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/

<https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/>

Our process for establishing whether third party libraries are
trusted before we use them:

 1. Build dependency check using Owasp
https://owasp.org/www-project-dependency-check/
<https://owasp.org/www-project-dependency-check/> Reject any
dependencies that fail, see
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml
<https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml>
line 87 for an example of a disabled module due to a
vulnerability in a dependency, the module will only be
re-enabled if the vulnerability is fixed.
 2. Static analysis using SpotBugs, then review identified bugs,
review source code if available.  Reject if security bugs are
present, or fix / patch.
 3. Profiling of permission access checks using:

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java

<https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java>
 4. 

Re: How to remove the SecurityManager

[Peter Firmstone]

On 28/07/2021 9:12 am, Peter Firmstone wrote:

While its possible to use a dynamic proxy without downloading code, 
via an atomic serialization connection, it's not generally advised to 
do so with unauthenticated users, decisions around dynamic discovery, 
whether class loading or downloads are allowed, it's all based on 
policy decisions.


Minor clarification / correction, it's not possible on our system to 
allow an unauthenticated user over a secure connection, our code 
disallows TLS connections with anon clients. We do provide TCP/IP 
connections, that are unsecured, however this is generally to allow 
testing of services during development and shouldn't be used in 
production.   No changes to a service need to be made other than 
configuration settings to enable secure connections.


Regards,

Peter.

Re: How to remove the SecurityManager

[Peter Firmstone]

, decisions around dynamic discovery, whether class 
loading or downloads are allowed, it's all based on policy decisions.


The problem with our software is its designed to operate on un-trusted 
networks, and SM infrastructure is involved in authorization decisions 
during the authentication process, as well as providing user credentials 
for secure connections.


We have no future Java migration path after JEP 411, the decision's been 
made, time to move on...


On the bright side, according the JEP 411, we did achieve what OpenJDK 
dev's thought to be almost impossible. :)   I'm pretty sure using the 
process I've documented above, you will identify 99% of accidental 
vulnerabilities in local code, and that was good enough for me lol.


The threat of accidental vulnerabilities in local code is almost 
impossible to address with the Security Manager.


* OpenBSD on Sparc (very well supported, Oracle should sell these lol, 
the only drawback is no zfs) is a good idea, no Spectre or Meltdown 
vulnerabilities.


buffy$ uname -a
OpenBSD buffy.lan 6.7 GENERIC.MP#310 sparc64

Although this one's a couple of versions behind, time for an upgrade.

Regards,

Peter.

On 28/07/2021 5:52 am, fo...@univ-mlv.fr wrote:

- Original Message -

From: "Alan Bateman" 
To: "Remi Forax" , "Peter Firmstone" 

Sent: Tuesday, July 27, 2021 6:33:25 PM
Subject: Re: How to remove the SecurityManager
On 27/07/2021 17:11, Remi Forax wrote:

Peter, this is how you remove the security manager using the jdk 17 (the
SystemMirror class is specific to a JDK version).

Any in-process security measures fail if the API let you to peek and poke the
memory like Unsafe does.

I hope you aren't really suggesting anyone does this :-)

nope, it's a small example to explain why in-process sandboxing is a bad idea.



It's dependent
on the field layout so can break and crash the VM if it doesn't match.
Also it assumes that someone gets theUnsafe before a SM is set.

yes, it's just an example, you have infinite variations using JNI/JNA/JNR or 
panama and changing some field value.


-Alan

Rémi

Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.

[Peter Firmstone]

matical theorems, I think that's why its taken years longer to 
stabilize.  By not having made compromises, it will likely be useful for 
much longer, even with some change.  It seems unlikely that an academic 
language would lose features due to budget constraints, it is more 
likely that inadequate or problematic features will be addressed and 
upgraded or replaced.


It is not so much that JEP 411 might break backward compatibility, we 
can live with that, what we are unable to address; it removes a feature 
that cannot be re-implemented and has no replacement, which exposes us 
to low probability, but unacceptable consequences.


There are no hard feelings, it's just a consequence of our original 
platform adoption choice, we knew there were risks.  It's time to move 
on and deal with it.  No doubt Java will be useful to many people for 
many years to come, and many don't require an authorization layer or 
chose something other than SM to implement one.  With no Java upgrade 
path, it leaves us free to choose from what is available now, rather 
than a choice made 20 years ago. In any case it's likely a choice that 
we would have needed to make eventually, JEP 411 has only brought it 
forward.   If Haskell is a magnitude more efficient, as its proponents 
claim, then it may ultimately provide an overall cost saving.   We 
haven't made a choice yet though, it's still under investigation.


I do appreciate that you took the time to respond to my emails.

Regards,

Peter.

On 26/07/2021 12:44 am, Alan Bateman wrote:

On 23/07/2021 23:33, Peter Firmstone wrote:
I think it's worth noting that there isn't a way to securely run code 
with malicious intent now, so I'm surprised that at this late stage 
you were still providing support for sand boxing (whack a mole).


It's just for us many assumptions have been made on a Java platform 
with SM, using POLP (not sandboxing) as this was one of the 
foundational principles of secure coding guidelines (just like 
following concurrency best practice, were were following security 
best practice).   Sandboxing is an all or nothing approach, if you 
had a trusted applet that was signed, it had AllPermission, if you 
had an unsigned applet, then it had no permissions.  Sandboxing was 
one of the use cases for SM, when combined with ClassLoader 
visibility, but we never realized that OpenJDK developers meant 
sandboxing == authorization access controls.


When you remove that pillar, everything it's supporting collapses, 
not just sand boxing, so when you say you are removing support for 
sandboxing, we say, good idea, but we didn't realize you were saying 
you were removing support for all authorization access controls.   
Reduced and revised authorization and access control would have been 
acceptable, as tightening reflection visibility using a different 
form of access control removes the need for authorization based 
reflection access checks, but also removing atomic construction 
guarantee's just seems like were doing this at a rapid pace without 
the community understanding what you have in mind, and this may have 
more uses than just stopping finalizer attacks. 
I'm not 100% sure what you mean by "atomic construction guarantee" 
here. This JEP does not propose to change anything with finalization 
or do anything with the registration of finalizers after Object. 
runs. Our exchange in the previous mails was about classes (using 
ClassLoader as the example) that specify a SM permission check in 
their constructors, something that is strongly discouraged as the 
checks are easy to bypass. The idiom that we use in the JDK to prevent 
bypassing these SM permission checks with a finalizer attack is to 
check in a static method that returns a dummy parameter for the 
invokespecial. My point in the previous mail is that when the SM 
permission checks eventually go away then many of the uses of this 
idiom can do away too.


That said, there is strong desire to eventually remove finalization 
too. Finalization was deprecated several years ago and the Java 
platform defines APIs that provide much more flexible and efficient 
ways do run cleanup actions when an object becomes unreachable. So 
another multi-year/multi-release effort to remove a problematic 
feature, just nothing to do with this JEP.


As regards POLP, the focus of SM architecture when it was enhanced in 
Java 1.2. The JEP attempts to explain why this has been a failure. 
AccessController is voodoo that most developers have never encountered 
so anyone trying to run with SM ends up running counter to the 
principle of least privilege by granting all permissions.


-Alan.

JEP 411: Sandboxing v's LOTJ (language other than Java) running on top of Java class libraries / JVM.

[Peter Firmstone]

I have established it's not practical to implement agents to intercept 
Java class libraries (Not the JVM) to guard access, such as class 
loading, properties, IO, etc.


It's also not practical to construct a Sandbox using ClassLoader, as has 
been suggested:


1. We would have to prevent access to java.lang.Class, to prevent code
   escaping the sandbox, this is far too restrictive.
2. It isn't practical to dynamically grant access, from within a sandbox.
3. The sandbox is an all or nothing approach.
4. The sandbox isn't an authorization layer.

Clearly Java in future, will be a zone of implicit trust, similarly to 
how we use C today from Java.


We need a "safer" language than Java, just like Java was a "safer" 
language than C.


This "safer" language would then allow authorization access controls, 
for network, file, class loading, data parsing, etc.


Rather than a sandbox, it just needs to be safer, with the ability to 
allow access to the underlying Java / C / etc, to trusted / 
authenticated / verified entities.


If anyone has any ideas regarding suitable languages, I'd be very 
interested to hear your thoughts.


--
Regards,
 
Peter Firmstone

Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.

[Peter Firmstone]

I think it's worth noting that there isn't a way to securely run code 
with malicious intent now, so I'm surprised that at this late stage you 
were still providing support for sand boxing (whack a mole).


It's just for us many assumptions have been made on a Java platform with 
SM, using POLP (not sandboxing) as this was one of the foundational 
principles of secure coding guidelines (just like following concurrency 
best practice, were were following security best practice).   Sandboxing 
is an all or nothing approach, if you had a trusted applet that was 
signed, it had AllPermission, if you had an unsigned applet, then it had 
no permissions.  Sandboxing was one of the use cases for SM, when 
combined with ClassLoader visibility, but we never realized that OpenJDK 
developers meant sandboxing == authorization access controls.


When you remove that pillar, everything it's supporting collapses, not 
just sand boxing, so when you say you are removing support for 
sandboxing, we say, good idea, but we didn't realize you were saying you 
were removing support for all authorization access controls.   Reduced 
and revised authorization and access control would have been acceptable, 
as tightening reflection visibility using a different form of access 
control removes the need for authorization based reflection access 
checks, but also removing atomic construction guarantee's just seems 
like were doing this at a rapid pace without the community understanding 
what you have in mind, and this may have more uses than just stopping 
finalizer attacks.  Unfortunately when you develop a feature, you can't 
be sure developers won't adapt and utilize it for multiple purposes.


Personally I think a better approach would have been to first reduce and 
simplify authorization access controls, replacing some of the 
functionality with different but more appropriate mechanisms.


Removing authorization access control features, without replacement 
means our software would be insecure, there isn't an obvious way to 
re-secure it, without re-architecting or re-designing it from the ground 
up, and Java is now a moving target anyway, so we would have to wait for 
it to re-stabilize as it transitions from Hippy to Hipster Java (just 
making a point it's not the same Java).


With this new understanding, we need to reconsider both the language and 
the platform that we'll be developing on.  Clearly a language with less 
boilerplate is an obvious start, I don't yet know which, we will still 
consider the JVM, but it would be with Kafka or Clojure, but then we 
also need to consider whether we will be able to secure the underlying 
platform, or at least use it securely.  Arguably we can do things now 
that aren't possible on other platforms, so we need to develop that 
capability as well, not just secure it.


Regards,

Peter.

On 23/07/2021 9:45 pm, Alan Bateman wrote:

On 23/07/2021 11:48, Peter Firmstone wrote:


Perhaps the solution is to replace the entire class, instead of 
instrumenting one method?


Compile a patched copy of the JVM, with modified class files, then 
replace the existing classes in the JVM with the modified classes?


Kinda like maintaining a fork, but using Agents to instrument the 
original JVM with classes from the fork?


I sure wish there was a better option, if anyone knows one, I'm all 
ears.


JEP 411 puts the JDK on the road to dropping support for sandboxing. 
This means there won't be a built-in means to securely run code that 
has malicious intent. It means that many of the concerns for finalizer 
attacks go away too. In the case of the ClassLoader example in your 
first mail then it may be that the private static method that you want 
to instrument will be removed. If removed, then it should make the 
instrumentation a bit easier so that you can instrument the protected 
constructors to invokestatic your equivalent of a permission check 
before the invokespecial. So I think this specific case is 
surmountable but in general I don't think it will be tenable to patch 
hundreds of classes and be confident that you've got everything, esp. 
with a moving code base and new features. I can't tell if your 
"authorization layer" is for use when running with code that has 
malicious intent. If it is, then I don't think it will be tenable to 
duplicate all the deeply invasive permission checks that exist today 
and keep it up to date as new features and changes. When agents were 
muted in the early discussion on JEP 411 then the context was file and 
network access where several people were interested in having a means 
to veto access. Expanding this to have a SM equivalent be able to veto 
every reflective access, prevent trusted method chain and other 
attacks, amounts to keeping the SM forever.


As regards the comments about agents having the power to instrument 
methods that aren't accessible to user code then that is normal. Java 
agents are for tools to do powerful things, they aren'

Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.

[Peter Firmstone]

Trusted code only, but it's intended to be run in a locked down 
principle of least privilege environment, while we perform static 
analysis and targeted review, we don't have the resources required to 
perform thorough trusted code audits, so have been reliant on the 
principle of least privilege.  Hence the ability to generate policy 
files that we use for auditing.


I utilize the constructor guarantee added in Java 6, that prevents 
finalizer attacks for atomic de-serialization, if invariants aren't 
satisfied, failure is atomic, thanks to this feature.


We use the SM to ensure network connections used are secure and only 
have authenticated users, otherwise de-serialization and dynamic class 
loading is prevented.


We don't need all the SM permission check features, but preventing 
unauthorized class loading is one of them.   Network, file access, class 
loading, properties are a few that come to mind, I'm not worried about 
reflection, other recent changes are taking care of reflective access. 
We have a heap of our own Permission implementations as well.


It appears that Java's future path is diverging from our software's 
needs and Java won't be a suitable platform in future. I wasn't aware 
that Java was heading in this direction.   JEP 411 came as a big 
surprise, it just seemed like it was a core Java feature.


I think the best course of action, will be to focus on Java 8, until 
that's EOL'd.   I do like the improvements to TLS stateless connections 
and new features in later Java versions, but it looks like a mistake to 
try and keep up with Java, with this new knowledge.  I think I'll back 
out some more recent changes that were intended to allow our software to 
run on Java 17, as these cause breakages for downstream developers and 
it doesn't seem to make much sense now, to make those breaking changes.  
I was actually looking forward to taking advantage of loom and the new 
vector API, but it looks like I need to be focused on what's going to be 
our next software platform.  I've always found llvm to be interesting, 
so maybe I'll focus on some languages that run on that, and implement 
privileged constraints at a lower level.


Perhaps by the time Java 8's EOL'd there will be a new platform and 
language that's more suitable.


Thank you for your time, I do appreciate your replies and it gives me 
the clarity I needed.


I wish it wasn't the case, but I have to accept that times are changing.

Best of luck for the future my Java friends, it's been a powerful 
language, especially with regard to concurrency and scaling, we got 
great performance, all our hotspots were native methods and Java let us 
get close to the metal at low levels as well using bit shift operations 
on primitives, that are magnitudes faster than standard string 
operations.   TLS ran so much faster with stateless session tickets too.


Regards,

Peter.

On 23/07/2021 9:45 pm, Alan Bateman wrote:

On 23/07/2021 11:48, Peter Firmstone wrote:


Perhaps the solution is to replace the entire class, instead of 
instrumenting one method?


Compile a patched copy of the JVM, with modified class files, then 
replace the existing classes in the JVM with the modified classes?


Kinda like maintaining a fork, but using Agents to instrument the 
original JVM with classes from the fork?


I sure wish there was a better option, if anyone knows one, I'm all 
ears.


JEP 411 puts the JDK on the road to dropping support for sandboxing. 
This means there won't be a built-in means to securely run code that 
has malicious intent. It means that many of the concerns for finalizer 
attacks go away too. In the case of the ClassLoader example in your 
first mail then it may be that the private static method that you want 
to instrument will be removed. If removed, then it should make the 
instrumentation a bit easier so that you can instrument the protected 
constructors to invokestatic your equivalent of a permission check 
before the invokespecial. So I think this specific case is 
surmountable but in general I don't think it will be tenable to patch 
hundreds of classes and be confident that you've got everything, esp. 
with a moving code base and new features. I can't tell if your 
"authorization layer" is for use when running with code that has 
malicious intent. If it is, then I don't think it will be tenable to 
duplicate all the deeply invasive permission checks that exist today 
and keep it up to date as new features and changes. When agents were 
muted in the early discussion on JEP 411 then the context was file and 
network access where several people were interested in having a means 
to veto access. Expanding this to have a SM equivalent be able to veto 
every reflective access, prevent trusted method chain and other 
attacks, amounts to keeping the SM forever.


As regards the comments about agents having the power to instrument 
methods that aren't accessible to user code then that is normal. Java 
agents are

Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.

[Peter Firmstone]

Perhaps the solution is to replace the entire class, instead of 
instrumenting one method?


Compile a patched copy of the JVM, with modified class files, then 
replace the existing classes in the JVM with the modified classes?


Kinda like maintaining a fork, but using Agents to instrument the 
original JVM with classes from the fork?


I sure wish there was a better option, if anyone knows one, I'm all ears.

Regards,

Peter.

On 23/07/2021 6:36 pm, Peter Firmstone wrote:
Post JEP 411, we need to write Agents to replace the current 
permission checks performed within the JVM by instrumenting it, 
following advice by OpenJDK developers, however for us this goes 
against all our previous development practices, no part of our 
codebase accesses any JDK implementation classes or internal api's.  
We also don't release anything that depends on deprecated API's.  
Modules didn't break our code, neither has tightening rules around 
access in JEP 403.


We have been advised that we need to instrument the JDK with Agent's 
by OpenJDK.


I am now ready to write these Agents, so that I can begin testing my 
new authorization layer for Java: 
https://github.com/pfirmstone/HighPerformanceSecurity


As an example, we need to instrument java.lang.ClassLoader, in this 
case we need to instrument the following method:


private static Void checkCreateClassLoader(String name);   This check 
must be performed prior to calling java.lang.Object's constructor, to 
throw an exception, without making ClassLoader susceptible to a 
finalizer attack.


Accessing private internal methods goes against all our current 
development practices, these are at risk of breaking in future.


We cannot add methods with Agent's only change method contents.

I am requesting hooks, in the form of an annotation, such as the 
following, so that OpenJDK developers know that this method will be 
instrumented by Agent's and not to change it's signature.


@Instrumented

private static Void checkCreateClassLoader(String name);

If OpenJDK will provide instrumentation hooks, then this is a workable 
solution for us.


Or is OpenJDK encouraging us to start accessing private methods and 
have to test each Java release for breakages?


I'm wondering what the point of JEP 403 is if, our solution to JEP 
411, is to start instrumenting private methods?   I don't think this 
is what OpenJDK developers are proposing.


Currently removing SM will allow an attacker to cause our software 
running on the JVM to parse untrusted data, which previously required 
an authenticated client?  Permission is only granted to Principal's, 
of course post JEP 411, these checks will stop working in future, 
making our software vulnerable to attacks by unauthenticated users.


We're still up in the air about how to provide credentials for our TLS 
and Kerberos connections, for authentication, I've created support for 
obtaining the Subject from the Authorization context, in my 
authorization layer software (linked above), but instrumenting private 
methods in the JDK goes against all previously learned best practices.


--
Regards,
  
Peter Firmstone


Code snippet from java.lang.ClassLoader:

if (name != null && name.isEmpty()) {

throw new IllegalArgumentException("name must be non-empty or null");

}


@SuppressWarnings("removal")

SecurityManager security = System.getSecurityManager();

if (security != null) {

security.checkCreateClassLoader();

}

return null;

}


private ClassLoader(Void unused, String name, ClassLoader parent) {

this.name = name;

this.parent = parent;

this.unnamedModule = new Module(this);

if (ParallelLoaders.isRegistered(this.getClass())) {

parallelLockMap = new ConcurrentHashMap<>();

assertionLock = new Object();

} else {

// no finer-grained lock; lock on the classloader instance

parallelLockMap = null;

assertionLock = this;

}

this.package2certs = new ConcurrentHashMap<>();

this.nameAndId = nameAndId(this);

}


/**

* If the defining loader has a name explicitly set then

* '' @

* If the defining loader has no name then

*  @

* If it's built-in loader then omit `@` as there is only one 
instance.


*/

private static String nameAndId(ClassLoader ld) {

String nid = ld.getName() != null ? "\'" + ld.getName() + "\'"

: ld.getClass().getName();

if (!(ld instanceof BuiltinClassLoader)) {

String id = Integer.toHexString(System.identityHashCode(ld));

nid = nid + " @" + id;

}

return nid;

}


/**

* Creates a new class loader of the specified name and using the

* specified parent class loader for delegation.

*

* @apiNote If the parent is specified as {@codenull} (for the

* bootstrap class loader) then there is no guarantee that all platform

* classes are visible.

*

* @param name class loader name; or {@codenull} if not named

* @param parent the parent class loader

*

* @throws IllegalArgumentException if the given name is empty.

*

* @throws SecurityExcep

JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.

[Peter Firmstone]

Post JEP 411, we need to write Agents to replace the current permission 
checks performed within the JVM by instrumenting it, following advice by 
OpenJDK developers, however for us this goes against all our previous 
development practices, no part of our codebase accesses any JDK 
implementation classes or internal api's. We also don't release anything 
that depends on deprecated API's. Modules didn't break our code, neither 
has tightening rules around access in JEP 403.


We have been advised that we need to instrument the JDK with Agent's by 
OpenJDK.


I am now ready to write these Agents, so that I can begin testing my new 
authorization layer for Java: 
https://github.com/pfirmstone/HighPerformanceSecurity


As an example, we need to instrument java.lang.ClassLoader, in this case 
we need to instrument the following method:


private static Void checkCreateClassLoader(String name);   This check 
must be performed prior to calling java.lang.Object's constructor, to 
throw an exception, without making ClassLoader susceptible to a 
finalizer attack.


Accessing private internal methods goes against all our current 
development practices, these are at risk of breaking in future.


We cannot add methods with Agent's only change method contents.

I am requesting hooks, in the form of an annotation, such as the 
following, so that OpenJDK developers know that this method will be 
instrumented by Agent's and not to change it's signature.


@Instrumented

private static Void checkCreateClassLoader(String name);

If OpenJDK will provide instrumentation hooks, then this is a workable 
solution for us.


Or is OpenJDK encouraging us to start accessing private methods and have 
to test each Java release for breakages?


I'm wondering what the point of JEP 403 is if, our solution to JEP 411, 
is to start instrumenting private methods?   I don't think this is what 
OpenJDK developers are proposing.


Currently removing SM will allow an attacker to cause our software 
running on the JVM to parse untrusted data, which previously required an 
authenticated client?  Permission is only granted to Principal's, of 
course post JEP 411, these checks will stop working in future, making 
our software vulnerable to attacks by unauthenticated users.


We're still up in the air about how to provide credentials for our TLS 
and Kerberos connections, for authentication, I've created support for 
obtaining the Subject from the Authorization context, in my 
authorization layer software (linked above), but instrumenting private 
methods in the JDK goes against all previously learned best practices.


--
Regards,
 
Peter Firmstone


Code snippet from java.lang.ClassLoader:

if (name != null && name.isEmpty()) {

throw new IllegalArgumentException("name must be non-empty or null");

}


@SuppressWarnings("removal")

SecurityManager security = System.getSecurityManager();

if (security != null) {

security.checkCreateClassLoader();

}

return null;

}


private ClassLoader(Void unused, String name, ClassLoader parent) {

this.name = name;

this.parent = parent;

this.unnamedModule = new Module(this);

if (ParallelLoaders.isRegistered(this.getClass())) {

parallelLockMap = new ConcurrentHashMap<>();

assertionLock = new Object();

} else {

// no finer-grained lock; lock on the classloader instance

parallelLockMap = null;

assertionLock = this;

}

this.package2certs = new ConcurrentHashMap<>();

this.nameAndId = nameAndId(this);

}


/**

* If the defining loader has a name explicitly set then

* '' @

* If the defining loader has no name then

*  @

* If it's built-in loader then omit `@` as there is only one instance.

*/

private static String nameAndId(ClassLoader ld) {

String nid = ld.getName() != null ? "\'" + ld.getName() + "\'"

: ld.getClass().getName();

if (!(ld instanceof BuiltinClassLoader)) {

String id = Integer.toHexString(System.identityHashCode(ld));

nid = nid + " @" + id;

}

return nid;

}


/**

* Creates a new class loader of the specified name and using the

* specified parent class loader for delegation.

*

* @apiNote If the parent is specified as {@codenull} (for the

* bootstrap class loader) then there is no guarantee that all platform

* classes are visible.

*

* @param name class loader name; or {@codenull} if not named

* @param parent the parent class loader

*

* @throws IllegalArgumentException if the given name is empty.

*

* @throws SecurityException

* If a security manager exists and its

* {@link SecurityManager#checkCreateClassLoader()}

* method doesn't allow creation of a new class loader.

*

* @since 9

*/

protected ClassLoader(String name, ClassLoader parent) {

this(checkCreateClassLoader(name), name, parent);

}
private static Void checkCreateClassLoader(String name) {

Re: JEP411: Missing use-case: Security Manager and Java Scripting (JSR 223)

[Peter Firmstone]

JEP 411 is quite a conundrum for downstream developers that depend on SM.

SecurityManager has its problems, but it's the only authorization layer 
we have.


If I had a complaint about SM, it's the implementation of:

1. SocketPermission doesn't allow netmask wild cards.
2. Thread inherited AccessControlContext and Executors.

My own implementations are not subject to the issues that the JVM's SM 
and Policy provider implementations suffer documented in JEP 411.


I think if authorization was redesigned from the ground up, Java would 
have a privileged mode, or privileged call (where permissions are 
checked) and everything else would be unprivileged, so there is no stack 
walk required for unpriviledged code, only privileged and it would be 
very short and not persist across threads.


Java has a very large API surface, compared to other languages.

It's a difficult decision to stick with Java, I keep looking at the 
other languages with their smaller API's , I keep wondering if I'm 
better off in the long term changing to another development language.  
OpenJDK has quite rightly identified that the cost of maintaining an 
authorization layer for Java is too high, given it's vast API surface 
area, it would be simpler to develop an authorization layer for another 
language with a smaller API.   For now I'm trying to stick with Java.  
But the reality is, I have until 2030 to transition if I revert to Java 
8, and Java 11 gets us through to 2029.  Java has some great new 
features, but they come at a cost.  Everything is a compromise, and one 
must select the right compromise. I have a lot of code I've developed in 
Java and have also invested a lot of time into it.   It is also likely 
there will be more deprecation for removal JEP's in future, I mean, 
someone might come up with the argument we don't require dynamic class 
loading, because that's for applets.  Dynamic class loading allows 
loading of untrusted code, so we should only allow trusted code to run 
that was installed statically by an administrator, because Java is only 
for Servers now.


This is the message I'm getting loud and clear, Java is only for servers 
in future.   I'm in the server space, but it's not the server model that 
OpenJDK developers have in mind.   This reminds me of the Unix 
workstation, with Unix retreating to servers then being replaced by Linux.


When is Java no longer Java?   Rather than continuing to evolve Java, 
why not use the JVM to create a new language project, or maybe a CVM 
(Clojure virtual machine?) which learns from the lessons of Java and let 
Java continue to be Java?


For now at least, I am trying to stick with Java, but it's not a clear 
decision.


It would be an easier decision to make if OpenJDK could provide some 
hooks where permission checks are currently made, so that we can 
implement our own authorization layer.


Anyway, these are just my personal thoughts and opinions, I do realize 
that they are probably unwelcome here.


Regards,

Peter.

On 22/07/2021 5:31 am, Sean Mullan wrote:

Hi,

I am not an expert in JSR 223. However, some JSR 223 implementations 
include a mechanism for restricting access to Java classes, for 
example Nashorn [1] and Rhino [2], which might be sufficient for your 
needs. (Note, Nashorn was deprecated and removed from JDK 15 [3]). I 
think most of the permissions you list below can be mapped to a small 
list of Java classes that check those permissions. Also, with strong 
encapsulation of JDK internals enforced by default in JDK 17 [4], you 
get additional protection that is not dependent on the Security Manager.


What JSR 223 implementation do you use?

--Sean

[1] 
https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html#classfilter_introduction
[2] 
https://mozilla.github.io/rhino/javadoc/org/mozilla/javascript/ClassShutter.html

[3] https://openjdk.java.net/jeps/372
[4] https://openjdk.java.net/jeps/403

On 7/21/21 12:35 PM, Alexey Shponarsky wrote:

Hello,

At Jelastic PaaS, we are using SecurityManager within Java Scripting 
(JSR 223). Specifically, Java Scripting allows us and our customers 
to easily extend the core platform functionality with custom logic. 
The developers can execute their custom scriptlets inside a Java 
Scripting runtime environment with pre-injected core platform API 
methods. For example,


//@req(pathFrom, pathTo)

varmountFrom = "${nodes.build.first.id }",

envName = "${settings.targetEnv}",

mountTo = "cp";

varresp = jelastic.env.file.RemoveMountPointByGroup(envName, session, 
mountTo, pathTo);


if(resp.result != 0) returnresp;

returnjelastic.env.file.AddMountPointByGroup(envName, session, 
mountTo, pathTo, 'nfs', null, pathFrom, mountFrom, '', false);


As Java Scripting engine / technology provides quite powerful 
runtimes, we have to restrict certains actions such as execution of 
any reflection methods, change of any system environment variables, 
exit, calling some 

Re: A few updates to JEP 411: Deprecate the Security Manager for Removal

[Peter Firmstone]

Thanks Sean,

Be nice if it can be implemented in a way that allows it to be decorated.

Regards,

Peter.

On 19/07/2021 10:29 pm, Sean Mullan wrote:



On 7/17/21 9:13 PM, Peter Firmstone wrote:

My mistake copied wrong bug:

Has there been any progress with the new Subject API?

https://bugs.openjdk.java.net/browse/JDK-8267108


Not yet, but I would like to see that done for JDK 18, so expect to 
see some progress on that in the next few months.


Thanks,
Sean



On 17/07/2021 2:53 pm, Peter Firmstone wrote:

Thanks Sean,

Has there been any progress with JDK-8264713?

https://bugs.openjdk.java.net/browse/JDK-8264713

Regards,

Peter.


On 16/07/2021 11:44 pm, Sean Mullan wrote:

JEP 411 has been updated with a few changes:

1. The "Description" section [1] has been updated with more details
on our plans for phasing out the Security Manager in Java 18 and 
later.


2. The "Issue warnings" section [2] has been updated with the warning
messages that are emitted at startup and run time when a Security
Manager has been enabled.

3. JEP 411 has been moved to the Completed state as all required
tasks have been completed.

Thanks,
Sean

[1] https://openjdk.java.net/jeps/411#Description
[2] https://openjdk.java.net/jeps/411#Issue-warnings

Re: Authorization layer - threads and privileged calls

[Peter Firmstone]

Note that the new authorization layer avoids "viral permissions" by 
requiring a privileged call before privileges will be enabled. Apart 
from privileged calls, only if a thread call stack contains all 
privileged domains, will it proceed with a Guard check.


The authorization layer doesn't define the granularity of Guard checks, 
that is up to the implementations.


This isn't working code yet, presently it's intended to communicate 
authorization concepts.  Hopefully OpenJDK will assist by providing some 
hooks in OpenJDK code for guard checks.


Latest update, more documentation:

https://github.com/pfirmstone/HighPerformanceSecurity/blob/main/HPS/src/main/java/au/net/zeus/auth/Authorization.java

Note this authorization layer also provides a way to preserve a user 
Subject across threads for authentication of TLS and Kerberos connections.


Peter.

On 17/07/2021 5:40 pm, Peter Firmstone wrote:


I've added the following method to the Authorization class:

/**
 * This method allows a developer to register the domain of a
 * dependency which doesn't utilize this Authorization layer, to be
 * considered as a trusted platform layer, in doing so however,
 * the dependency should be audited for vulnerabilities and 
instrumented

 * with guards if necessary.
 *
 * The intent of this method, is to allow guards to check the domains
 * on a thread call stack which hasn't originated from a 
privileged call,
 * the privileges of the domain are still checked, however it is 
preferable
 * for privileged calls to wrap and encapsulate dependency code if 
possible.
 * In the event that dependency code creates its own worker 
threads internally
 * which require privileges, this method allows those privileges 
to be checked,

 * rather than immediately rejected.
 *
 * However dependency code is unlikely to discriminate between 
calling code

 * and as such may allow other code to call it also, which may open
 * authorization security vulnerabilities.  In this case, the 
developer
 * may request the dependency code developers to add support, or 
may instrument the

 * dependency code with guard checks using the Attach API.
 * Alternatively a developer may wish to use module or ClassLoader 
visibility,

 * to isolate the dependency code.
 *
 * @param cl a class belonging to the privileged domain.
 */
    public static void registerPrivileged(Class cl){
    GUARD_PRIVILEGED_CHECK.checkGuard(cl);
    Authorization authorization = INHERITED_CONTEXT.get();
    try {
    INHERITED_CONTEXT.set(PRIVILEGED);
    PRIVILEGED_DOMAINS.add(cl.getProtectionDomain());
    } finally {
    INHERITED_CONTEXT.set(authorization);
    }
    }

On 16/07/2021 2:20 pm, Peter Firmstone wrote:


I'm currently experimenting with a new authorization layer for java, 
post JEP 411.


I would like your thoughts around threads.

This is intended to be simpler than Java's existing authorization 
layer, support user Subjects and code based authorization.


Concepts:

 1. Application code has no privileges, unless a privileged call is
made (implements Callable), the privileges are only in force
during execution of the Callable and are not transferable to
other threads.
 2. A Thread with a stack that only contains code visible to the
platform ClassLoader is considered privileged.
 3. Privileged means it has defined privileges, it doesn't mean
AllPermission.

Agents will be used to instrument the Java API for guard checks 
(would be nice if OpenJDK can annotate these methods or do something 
to help us identify these locations).


Clearly, this will break a lot of existing code, many applications 
simply won't run, because they don't utilise the API.  It would work 
fine for new applications.


In Java's existing authorization layer implementation (designed prior 
to the introduction of Executor frameworks), a thread inherits the 
stack context of the thread which created it, with executors, tasks 
don't inherit the context of the thread which places the task.  The 
new framework isn't able to capture the creating threads context, so 
it makes more sense to treat anything outside a privileged call, or 
system thread as unprivileged, it does however capture the caller 
when creating a privileged task, this is a Task that has privileged 
access, so it's important that it is not allowed to escape.


I am thinking about allowing privileged domains, such that if a 
library (which doesn't implement privileged calls), may be thought of 
as a system domain, should it create threads, then provided those 
threads only have privileged domains on the stack, guard checks may 
proceed.   For unprivileged application code, all guard checks fail.


Any thoughts or questions?

Re: A few updates to JEP 411: Deprecate the Security Manager for Removal

[Peter Firmstone]

My mistake copied wrong bug:

Has there been any progress with the new Subject API?

https://bugs.openjdk.java.net/browse/JDK-8267108

On 17/07/2021 2:53 pm, Peter Firmstone wrote:

Thanks Sean,

Has there been any progress with JDK-8264713?

https://bugs.openjdk.java.net/browse/JDK-8264713

Regards,

Peter.


On 16/07/2021 11:44 pm, Sean Mullan wrote:

JEP 411 has been updated with a few changes:

1. The "Description" section [1] has been updated with more details 
on our plans for phasing out the Security Manager in Java 18 and later.


2. The "Issue warnings" section [2] has been updated with the warning 
messages that are emitted at startup and run time when a Security 
Manager has been enabled.


3. JEP 411 has been moved to the Completed state as all required 
tasks have been completed.


Thanks,
Sean

[1] https://openjdk.java.net/jeps/411#Description
[2] https://openjdk.java.net/jeps/411#Issue-warnings



--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: Authorization layer - threads and privileged calls

[Peter Firmstone]

I've added the following method to the Authorization class:

/**
 * This method allows a developer to register the domain of a
 * dependency which doesn't utilize this Authorization layer, to be
 * considered as a trusted platform layer, in doing so however,
 * the dependency should be audited for vulnerabilities and 
instrumented

 * with guards if necessary.
 *
 * The intent of this method, is to allow guards to check the domains
 * on a thread call stack which hasn't originated from a privileged 
call,
 * the privileges of the domain are still checked, however it is 
preferable
 * for privileged calls to wrap and encapsulate dependency code if 
possible.
 * In the event that dependency code creates its own worker threads 
internally
 * which require privileges, this method allows those privileges to 
be checked,

 * rather than immediately rejected.
 *
 * However dependency code is unlikely to discriminate between 
calling code

 * and as such may allow other code to call it also, which may open
 * authorization security vulnerabilities.  In this case, the developer
 * may request the dependency code developers to add support, or 
may instrument the

 * dependency code with guard checks using the Attach API.
 * Alternatively a developer may wish to use module or ClassLoader 
visibility,

 * to isolate the dependency code.
 *
 * @param cl a class belonging to the privileged domain.
 */
    public static void registerPrivileged(Class cl){
    GUARD_PRIVILEGED_CHECK.checkGuard(cl);
    Authorization authorization = INHERITED_CONTEXT.get();
    try {
    INHERITED_CONTEXT.set(PRIVILEGED);
    PRIVILEGED_DOMAINS.add(cl.getProtectionDomain());
    } finally {
    INHERITED_CONTEXT.set(authorization);
    }
    }

On 16/07/2021 2:20 pm, Peter Firmstone wrote:


I'm currently experimenting with a new authorization layer for java, 
post JEP 411.


I would like your thoughts around threads.

This is intended to be simpler than Java's existing authorization 
layer, support user Subjects and code based authorization.


Concepts:

 1. Application code has no privileges, unless a privileged call is
made (implements Callable), the privileges are only in force
during execution of the Callable and are not transferable to other
threads.
 2. A Thread with a stack that only contains code visible to the
platform ClassLoader is considered privileged.
 3. Privileged means it has defined privileges, it doesn't mean
AllPermission.

Agents will be used to instrument the Java API for guard checks (would 
be nice if OpenJDK can annotate these methods or do something to help 
us identify these locations).


Clearly, this will break a lot of existing code, many applications 
simply won't run, because they don't utilise the API.  It would work 
fine for new applications.


In Java's existing authorization layer implementation (designed prior 
to the introduction of Executor frameworks), a thread inherits the 
stack context of the thread which created it, with executors, tasks 
don't inherit the context of the thread which places the task.  The 
new framework isn't able to capture the creating threads context, so 
it makes more sense to treat anything outside a privileged call, or 
system thread as unprivileged, it does however capture the caller when 
creating a privileged task, this is a Task that has privileged access, 
so it's important that it is not allowed to escape.


I am thinking about allowing privileged domains, such that if a 
library (which doesn't implement privileged calls), may be thought of 
as a system domain, should it create threads, then provided those 
threads only have privileged domains on the stack, guard checks may 
proceed.   For unprivileged application code, all guard checks fail.


Any thoughts or questions?

--
Regards,
  
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.


--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: A few updates to JEP 411: Deprecate the Security Manager for Removal

[Peter Firmstone]

Thanks Sean,

Has there been any progress with JDK-8264713?

https://bugs.openjdk.java.net/browse/JDK-8264713

Regards,

Peter.


On 16/07/2021 11:44 pm, Sean Mullan wrote:

JEP 411 has been updated with a few changes:

1. The "Description" section [1] has been updated with more details on 
our plans for phasing out the Security Manager in Java 18 and later.


2. The "Issue warnings" section [2] has been updated with the warning 
messages that are emitted at startup and run time when a Security 
Manager has been enabled.


3. JEP 411 has been moved to the Completed state as all required tasks 
have been completed.


Thanks,
Sean

[1] https://openjdk.java.net/jeps/411#Description
[2] https://openjdk.java.net/jeps/411#Issue-warnings

Authorization layer - threads and privileged calls

[Peter Firmstone]

I'm currently experimenting with a new authorization layer for java, 
post JEP 411.


I would like your thoughts around threads.

This is intended to be simpler than Java's existing authorization layer, 
support user Subjects and code based authorization.


Concepts:

1. Application code has no privileges, unless a privileged call is made
   (implements Callable), the privileges are only in force during
   execution of the Callable and are not transferable to other threads.
2. A Thread with a stack that only contains code visible to the
   platform ClassLoader is considered privileged.
3. Privileged means it has defined privileges, it doesn't mean
   AllPermission.

Agents will be used to instrument the Java API for guard checks (would 
be nice if OpenJDK can annotate these methods or do something to help us 
identify these locations).


Clearly, this will break a lot of existing code, many applications 
simply won't run, because they don't utilise the API.  It would work 
fine for new applications.


In Java's existing authorization layer implementation (designed prior to 
the introduction of Executor frameworks), a thread inherits the stack 
context of the thread which created it, with executors, tasks don't 
inherit the context of the thread which places the task.  The new 
framework isn't able to capture the creating threads context, so it 
makes more sense to treat anything outside a privileged call, or system 
thread as unprivileged, it does however capture the caller when creating 
a privileged task, this is a Task that has privileged access, so it's 
important that it is not allowed to escape.


I am thinking about allowing privileged domains, such that if a library 
(which doesn't implement privileged calls), may be thought of as a 
system domain, should it create threads, then provided those threads 
only have privileged domains on the stack, guard checks may proceed.   
For unprivileged application code, all guard checks fail.


Any thoughts or questions?

--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

Updated authorization layer prototype:

https://github.com/pfirmstone/HighPerformanceSecurity

On 30/06/2021 9:38 pm, Peter Firmstone wrote:

A draft Authorization implementation, untested.


--
Regards,
 
Peter Firmstone

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

A draft Authorization implementation, untested.

--
Regards,
 
Peter Firmstone



/**
 * Authorization class, instances contain the domains and Subject of the
 * Authorization context, used for Authorization decisions by Guard
 * implementations.  Provides static utility methods to make 
privilgedCall's

 * and record the current context.
 *
 * @author peter
 */
public final class Authorization {

    private static final ProtectionDomain MY_DOMAIN = 
Authorization.class.getProtectionDomain();


    private static final Authorization PRIVILEGED =
    new Authorization(new ProtectionDomain []{ MY_DOMAIN });

    private static final Authorization UNPRIVILEGED
    = new Authorization(
    new ProtectionDomain[]{
    new ProtectionDomain(
    new CodeSource(null, (Certificate [])null), null
    )
    }
    );

    private static final ThreadLocal INHERITED_CONTEXT
    = new ThreadLocal();

    private static final Guard GUARD_REGISTER_CHECK =
    GuardBuilder.getInstance("RUNTIME").get("registerGuard", 
(String) null);


    private static final Guard GUARD_SUBJECT =
GuardBuilder.getInstance("AUTH").get("getSubjectFromAuthorization", null);

    private static final Set> GUARDS =
    RC.set(Collections.newSetFromMap(new 
ConcurrentHashMap<>()), Ref.WEAK, 0);




    /**
 * Elevates the privileges of the Callable to those granted to the 
Subject
 * and ProtectionDomain's of the Callable and it's call stack, 
including the

 * ProtectionDomain of the caller of this method.
 *
 * @param 
 * @param c
 * @return
 */
    public static  Callable privilegedCall(Callable c){
    Authorization auth = INHERITED_CONTEXT.get();
    try {
    INHERITED_CONTEXT.set(PRIVILEGED);
    if (auth != null){
    return privilegedCall(auth.getSubject(), c);
    } else {
    return new CallableWrapper<>(new 
Authorization(captureCallerDomain(null), null), c);

    }
    } finally {
    INHERITED_CONTEXT.set(auth);
    }
    }

    /**
 * Elevates the privileges of the Callable to those granted to the 
Subject
 * and ProtectionDomain's of the Callable and it's call stack, 
including the

 * ProtectionDomain of the caller of this method.
 *
 * @param 
 * @param subject
 * @param c
 * @return
 */
    public static  Callable privilegedCall(Subject subject, 
Callable c){

    Authorization authorization = INHERITED_CONTEXT.get();
    try {
    INHERITED_CONTEXT.set(PRIVILEGED);
    Set p = subject != null ? 
subject.getPrincipals() : null;
    Principal [] principals = p != null ? p.toArray(new 
Principal[p.size()]) : null;
    return new CallableWrapper<>(new 
Authorization(captureCallerDomain(principals), subject), c);

    } finally {
    INHERITED_CONTEXT.set(authorization);
    }
    }

    /**
 * Elevates the privileges of the Callable to those granted to the 
Subject
 * and ProtectionDomain's of the Callable and it's call stack, 
including the

 * ProtectionDomain of the caller of this method and the Authorization
 * context provided.
 *
 * @param 
 * @param ac
 * @param c
 * @return
 */
    public static  Callable privilegedCall(Authorization ac, 
Callable c){
    if (c == null) throw new IllegalArgumentException("Callable 
cannot be null");

    if (ac != null){
    Authorization authorization = INHERITED_CONTEXT.get();
    try {
    INHERITED_CONTEXT.set(PRIVILEGED);
    Subject subject = ac.getSubject();
    Set p = subject != null ? 
subject.getPrincipals() : null;
    Principal [] principals = p != null ? p.toArray(new 
Principal[p.size()]) : null;
    Set domains = 
captureCallerDomain(principals);

    ac.checkEach((ProtectionDomain t) -> {
    if (MY_DOMAIN.equals(t)) return;
    if (principals != null){
    domains.add(
    new ProtectionDomainKey(t, principals)
    );
    } else {
    domains.add(new ProtectionDomainKey(t));
    }
    });
    Authorization auth = new Authorization(domains, subject);
    return new CallableWrapper<>(auth, c);
    } finally {
    INHERITED_CONTEXT.set(authorization);
    }
    } else {
    return privilegedCall(c);
    }
    }

    private static Set captureCallerDomain(Principal 
[] principals){

    Set options = new HashSet<>();
    options.add(Option.RETAIN_CLASS_REFERENCE);
    StackWalker walker = StackWalker.getInstance(options

Re: READ 1ST: Re: Authorization layer API and low level access checks

[Peter Firmstone]

 , if Module
   isNamed(), retrieved from Class.getModule().
 o Authorization agents will be considered platform code.
 * At the time Authorization.getContext() is called, the inherited
   context will be combined with the stack walk from the current
   thread and the all domains will include the Subject's principals.

6. GuardFactory and GuardFactorySpi, Authorization agents will need to
   call GuardFactory, to obtain Guard instances, the Guard
   implementation can call:
 * Authorization::getContext()checkEach(domain -> doSomething(domain));

--
Regards,
 
Peter Firmstone


On 26/06/2021 10:05 pm, Peter Firmstone wrote:



On 26/06/2021 3:41 pm, Peter Firmstone wrote:


Apologies for multiple earlier emails, please ignore and read this 
instead.


This proposal is about stripping out and simplifying as much of the 
dilapidated and complex SecurityManager infrastructure as possible, 
while retaining the ability for developers to implement a better high 
scaling and performant Authorization layer, without prohibitively 
preventing it.


Summary of Proposed Changes:

 1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (Note GuardFactory
should never return null and instead return a no-op Guard that
hotspot can optimize out.
 2. Existing Permission implementations to be obtained using
GuardFactorySpi implementations, until their removal.  Note that
when SecurityManager is stubbed out and Permission
implementations are deprecated for removal, these should no
longer be provided by default, but instead need to be enabled by
entries in the java.security config file, in preparation for
their removal.
 3. JDK code to no longer call Permission implementations directly,
instances obtained using GuardFactory, when enabled in the
java.security configuration file.
 4. Threads (system and virtual) updated to use a singleton
*unprivileged* AccessControlContext, instead of inherited
AccessControlContext, this is more appropriate for Executors, the
original inherited context was designed before Executors were
introduced.
 5. Deprecation for removal of all Permission implementations from
the JDK platform.   The existing implementations of Permission
introduce unnecessary complexity; they lack sufficient
flexibility resulting in a proliferation of Permission grants
required in policy files and some make blocking network calls.
 6. Introduce a system property to change AccessController's default
behaviour, disable the stack walk by default, but allow it to be
re-enabled with a system property, replace the stack walk array
result of ProtectionDomains with an *unprivileged*
AccessControlContext, the SubjectDomainCombiner can replace it
with a, AccessControlContext containing a single element array,
containing one ProtectionDomain with Principals.
 7. AccessController::doPrivileged erases the DomainCombiner by
default, deprecate these methods for removal (make private),
retain doPrivilegedWithCombiner methods that preserve the
SubjectDomainCombiner.   Developers should replace their
doPrivileged methods with doPrivilegedWithCombiner.   Create a
new method AccessController::doUnprivileged, clear intent, to
erase the DomainCombiner, and use the *unprivileged*
AccessControlContext.  Update
AccessController.AccHolder.innocuousAcc to refer to an
*unprivileged* context, as per the definition below.
 8. Deprecate for removal the CodeSource::implies method.
 9. Give unique ProtectionDomain's with a meaninful CodeSource to
Java modules mapped to the boot loader, rather than using a
Shared ProtectionDomain with a null CodeSource.
10. Deprecate for removal AccessController::checkPermission and
AccessControlContext::checkPermission methods.

AccessController.checkPermission calls AccessControlContext.optimize, 
which invokes the DomainCombiner, prior to calling 
AccessControlContext.checkPermission


In my implementation of SecurityManager, I call 
AccessController.getContext from within a PrivilegedAction, to 
optimise a newly created AccessControlContext, 
(AccessController.getContext also calls AcessControlConext.optimize), 
prior to calling AccessControlContext.checkPermission.


I think it would be simpler however, to create a new method in 
AccessController to replace checkPermission which also calls optimize.


I think something could be done here with Stream and Consumer to 
perform the function checking ProtectionDomain's.  Needs a little more 
thought, but basically we want to be able to check each 
ProtectionDomain, without being restricted to Permission or Policy 
implementations.


Eg:

AccessController.stream(AccessControlContext context).forEach(domain 
-> Check::domain)


Or

AccessController.checkDomains(AccessControlContext context, 
Consumer)


This method would have a relevant G

Re: READ 1ST: Re: Authorization layer API and low level access checks

[Peter Firmstone]

On 26/06/2021 3:41 pm, Peter Firmstone wrote:


Apologies for multiple earlier emails, please ignore and read this 
instead.


This proposal is about stripping out and simplifying as much of the 
dilapidated and complex SecurityManager infrastructure as possible, 
while retaining the ability for developers to implement a better high 
scaling and performant Authorization layer, without prohibitively 
preventing it.


Summary of Proposed Changes:

 1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (Note GuardFactory
should never return null and instead return a no-op Guard that
hotspot can optimize out.
 2. Existing Permission implementations to be obtained using
GuardFactorySpi implementations, until their removal.  Note that
when SecurityManager is stubbed out and Permission implementations
are deprecated for removal, these should no longer be provided by
default, but instead need to be enabled by entries in the
java.security config file, in preparation for their removal.
 3. JDK code to no longer call Permission implementations directly,
instances obtained using GuardFactory, when enabled in the
java.security configuration file.
 4. Threads (system and virtual) updated to use a singleton
*unprivileged* AccessControlContext, instead of inherited
AccessControlContext, this is more appropriate for Executors, the
original inherited context was designed before Executors were
introduced.
 5. Deprecation for removal of all Permission implementations from the
JDK platform.   The existing implementations of Permission
introduce unnecessary complexity; they lack sufficient flexibility
resulting in a proliferation of Permission grants required in
policy files and some make blocking network calls.
 6. Introduce a system property to change AccessController's default
behaviour, disable the stack walk by default, but allow it to be
re-enabled with a system property, replace the stack walk array
result of ProtectionDomains with an *unprivileged*
AccessControlContext, the SubjectDomainCombiner can replace it
with a, AccessControlContext containing a single element array,
containing one ProtectionDomain with Principals.
 7. AccessController::doPrivileged erases the DomainCombiner by
default, deprecate these methods for removal (make private),
retain doPrivilegedWithCombiner methods that preserve the
SubjectDomainCombiner.   Developers should replace their
doPrivileged methods with doPrivilegedWithCombiner.   Create a new
method AccessController::doUnprivileged, clear intent, to erase
the DomainCombiner, and use the *unprivileged*
AccessControlContext.  Update
AccessController.AccHolder.innocuousAcc to refer to an
*unprivileged* context, as per the definition below.
 8. Deprecate for removal the CodeSource::implies method.
 9. Give unique ProtectionDomain's with a meaninful CodeSource to Java
modules mapped to the boot loader, rather than using a Shared
ProtectionDomain with a null CodeSource.
10. Deprecate for removal AccessController::checkPermission and
AccessControlContext::checkPermission methods.

AccessController.checkPermission calls AccessControlContext.optimize, 
which invokes the DomainCombiner, prior to calling 
AccessControlContext.checkPermission


In my implementation of SecurityManager, I call 
AccessController.getContext from within a PrivilegedAction, to optimise 
a newly created AccessControlContext, (AccessController.getContext also 
calls AcessControlConext.optimize), prior to calling 
AccessControlContext.checkPermission.


I think it would be simpler however, to create a new method in 
AccessController to replace checkPermission which also calls optimize.


I think something could be done here with Stream and Consumer to perform 
the function checking ProtectionDomain's.  Needs a little more thought, 
but basically we want to be able to check each ProtectionDomain, without 
being restricted to Permission or Policy implementations.


Eg:

AccessController.stream(AccessControlContext context).forEach(domain -> 
Check::domain)


Or

AccessController.checkDomains(AccessControlContext context, 
Consumer)


This method would have a relevant Guard.check "RUNTIME" 
"getProtectionDomain" prior to calling AccessControlContext.optimize and 
the developer would need to make the call from a PrivilegedAction, and 
remember pass the relevant guard check for it's own AccessControlContext.



11. Undeprecate AccessController, AccessControlContext,
DomainCombiner, SubjectDomainCombiner and Subject::doAs methods,
while deprecating for removal methods stated in items above.
12. Deprecate for removal ProtectionDomain::implies,
ProtectionDomain::getPermissions and
ProtectionDomain::staticPermissionsOnly
13. Replace PermissionCollection type argument with Object in
Pr

READ 1ST: Re: Authorization layer API and low level access checks

[Peter Firmstone]

ward 
compatibility. Update ProtectionDomain::implies method, to *not* consult 
with the Policy.  Note it's possible to get access to the 
ProtectionDomain array contained within AccessControlContext using a 
DomainCombiner.


This is backward compatible with existing usages of JAAS and least 
painful method of transition for all concerned as well as allowing 
complete flexibility of implementation.


Regards,

Peter Firmstone.

On 25/06/2021 3:59 pm, Peter Firmstone wrote:

Thanks Dalibor,

Would targeting Java 18 be practical?

Also it won't take long to code a prototype, just not sure of the 
process.


Cheers,

Peter.


On 24/06/2021 9:30 pm, Dalibor Topic wrote:

On 24.06.2021 04:24, Peter Firmstone wrote:

Thanks Andrew,

For the simple case, of replacing the SecurityManager stack walk, 
one could use reflection.


Thank you for also confirming that is not possible (or at least very 
unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK 
code to use a provider mechanism, to intercept permission checks, so 
custom authentication layers can be implemented, this could be 
accepted in future versions of Java, but not existing. As it is 
said, there is no harm in asking.


Generally speaking, adding any public APIs to a platform release 
after its specification has been published, is always going to be a 
very tall order involving the JCP, among other things. It's not 
really worth it, when other technical solutions, such as 
multi-release JARs, already exist, that alleviate the necessity.


cheers,
dalibor topic

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

Inline.

On 26/06/2021 1:46 pm, Peter Firmstone wrote:


Inline below.

On 26/06/2021 1:11 pm, Peter Firmstone wrote:


One more proposed change inline:

On 26/06/2021 12:58 pm, Peter Firmstone wrote:


Summary of Proposed Changes:

 1. GuardFactory & GuardFactorySpi to provide hooks for
authorization checks without SecurityManager or Policy. (Note
GuardFactory should never return null and instead return a no-op
Guard that hotspot can optimize out.
 2. Existing Permission implementations to be obtained using
GuardFactorySpi implementations, until their removal. Note that
when SecurityManager is stubbed out and Permission
implementations are deprecated for removal, these should no
longer be provided by default, but instead need to be enabled by
entries in the java.security config file, in preparation for
their removal.
 3. JDK code, no longer call Permission implementations directly,
instances obtained using GuardFactory, only when enabled in the
java.security configuration file.
 4. Threads (system and virtual) updated to use a singleton
*unprivileged* AccessControlContext, instead of inherited
AccessControlContext, this is more appropriate for Executors,
the original inherited context was designed before Executors
were introduced.
 5. Deprecation for removal of all Permission implementations from
the JDK platform.   The existing implementations of Permission
introduce unnecessary complexity; they lack sufficient
flexibility resulting in a proliferation of Permission grants
required in policy files and some make blocking network calls.
 6. Introduce a system property to change AccessController default
behaviour, disable the stack walk by default, but allow it to be
re-enabled with a system property, replace the stack walk array
result of ProtectionDomains with an *unprivileged*
AccessControlContext, the SubjectDomainCombiner can replace it
with a, AccessControlContext containing a single element array,
containing one ProtectionDomain with Principals.
 7. AccessController::doPrivileged erases the DomainCombiner by
default, deprecate these methods, retain
doPrivilegedWithCombiner methods that preserve the
SubjectDomainCombiner.   Developers should replace their
doPrivileged methods with doPrivilegedWithCombiner



Just thinking out loud, it's possible someone might want to do perform 
some task without privileges enabled, that is without the Subject's 
principal's.   In a system that grants privileges to code and 
principals, this is generally unnecessary, as grants are made to the 
combination of code and principals.  However while using the 
doPrivileged methods is possible, to remove privileges, it would be 
better to provide an AccessController::doUnprivileged method instead, 
which erase the DomainCombiner and use an *unprivileged* 
AccessControlContext.


Since the doPrivileged methods are utilised by other methods in 
AccessController, they should be made private when finally deprecated 
for removal.


I have also just noticed a bug in AccessController.AccHolder.innocuousAcc.



I need to make some clarifications here:

The ProtectionDomain::getPermissions() method determines whether a 
domain is privileged if it contains AllPermission.


Since future implementations might not use Permission's to determine 
privileges, and privileges may be determined by CodeSource or 
Principal's, a null CodeSource is used to indicate a domain belonging to 
the bootstrap ClassLoader.



The innocuous AccessControlContext, is intended to have no permission, 
hence it is constructed using the two argument ProtectionDomain 
constructor, which causes ProtectionDomain to not consult the Policy.


However, if a user obtains this ProtectionDomain and asks the Policy 
for the ProtectionDomain's permission's by calling 
Policy::getPermissions(ProtectionDomain), the Policy will return 
AllPermission.




This is incorrect, as the ProtectionDomain contains a null 
PermissionCollection, my mistake.


However I still propose it be changed, due to the association of a null 
CodeSource with bootstrap ClassLoader domains.


It is generally understood that a ProtectionDomain with a null 
CodeSource is a system ProtectionDomain loaded by the bootstrap 
ClassLoader.


I propose that innocuous AccessControlContext instead be given a 
ProtectionDomain, with a non-null CodeSource, which has a null URL.  
This is also considered by the Policy to be unprivileged.




    8. Deprecate for removal the CodeSource::implies method.

    9. Give unique ProtectionDomain's with a meaninful CodeSource to 
Java modules mapped to the boot loader, rather than using a Shared 
ProtectionDomain with a null CodeSource.


    10. Deprecate for removal AccessController::checkPermission and 
AccessControlContext::checkPermission methods.


    11. Undeprecate AccessController, AccessControlContext, 
DomainCombiner, SubjectDomainComb

Re: Logic bug in AccessController.AccHolder.innocuousAcc

[Peter Firmstone]

On 26/06/2021 1:48 pm, Peter Firmstone wrote:
The innocuous AccessControlContext, is intended to have no permission, 
hence it is constructed using the two argument ProtectionDomain 
constructor, which causes ProtectionDomain to not consult the Policy.


However, if a user obtains this ProtectionDomain and asks the Policy 
for the ProtectionDomain's permission's by calling 
Policy::getPermissions(ProtectionDomain), the Policy will return 
AllPermission.



Apologies, the Policy won't return AllPermission, my mistake.




It is generally understood that a ProtectionDomain with a null 
CodeSource is a system ProtectionDomain loaded by the bootstrap 
ClassLoader.


I propose that innocuous AccessControlContext instead be given a 
ProtectionDomain, with a non-null CodeSource, which has a null URL. 
This is also considered by the Policy to be unprivileged.



--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Logic bug in AccessController.AccHolder.innocuousAcc

[Peter Firmstone]

The innocuous AccessControlContext, is intended to have no permission, 
hence it is constructed using the two argument ProtectionDomain 
constructor, which causes ProtectionDomain to not consult the Policy.


However, if a user obtains this ProtectionDomain and asks the Policy for 
the ProtectionDomain's permission's by calling 
Policy::getPermissions(ProtectionDomain), the Policy will return 
AllPermission.


It is generally understood that a ProtectionDomain with a null 
CodeSource is a system ProtectionDomain loaded by the bootstrap ClassLoader.


I propose that innocuous AccessControlContext instead be given a 
ProtectionDomain, with a non-null CodeSource, which has a null URL. This 
is also considered by the Policy to be unprivileged.


--
Regards,
 
Peter Firmstone

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

Inline below.

On 26/06/2021 1:11 pm, Peter Firmstone wrote:


One more proposed change inline:

On 26/06/2021 12:58 pm, Peter Firmstone wrote:


Summary of Proposed Changes:

 1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (Note GuardFactory
should never return null and instead return a no-op Guard that
hotspot can optimize out.
 2. Existing Permission implementations to be obtained using
GuardFactorySpi implementations, until their removal.  Note that
when SecurityManager is stubbed out and Permission
implementations are deprecated for removal, these should no
longer be provided by default, but instead need to be enabled by
entries in the java.security config file, in preparation for
their removal.
 3. JDK code, no longer call Permission implementations directly,
instances obtained using GuardFactory, only when enabled in the
java.security configuration file.
 4. Threads (system and virtual) updated to use a singleton
*unprivileged* AccessControlContext, instead of inherited
AccessControlContext, this is more appropriate for Executors, the
original inherited context was designed before Executors were
introduced.
 5. Deprecation for removal of all Permission implementations from
the JDK platform.   The existing implementations of Permission
introduce unnecessary complexity; they lack sufficient
flexibility resulting in a proliferation of Permission grants
required in policy files and some make blocking network calls.
 6. Introduce a system property to change AccessController default
behaviour, disable the stack walk by default, but allow it to be
re-enabled with a system property, replace the stack walk array
result of ProtectionDomains with an *unprivileged*
AccessControlContext, the SubjectDomainCombiner can replace it
with a, AccessControlContext containing a single element array,
containing one ProtectionDomain with Principals.
 7. AccessController::doPrivileged erases the DomainCombiner by
default, deprecate these methods, retain doPrivilegedWithCombiner
methods that preserve the SubjectDomainCombiner.   Developers
should replace their doPrivileged methods with
doPrivilegedWithCombiner



Just thinking out loud, it's possible someone might want to do perform 
some task without privileges enabled, that is without the Subject's 
principal's.   In a system that grants privileges to code and 
principals, this is generally unnecessary, as grants are made to the 
combination of code and principals.  However while using the 
doPrivileged methods is possible, to remove privileges, it would be 
better to provide an AccessController::doUnprivileged method instead, 
which erase the DomainCombiner and use an *unprivileged* 
AccessControlContext.


Since the doPrivileged methods are utilised by other methods in 
AccessController, they should be made private when finally deprecated 
for removal.


I have also just noticed a bug in AccessController.AccHolder.innocuousAcc.

The innocuous AccessControlContext, is intended to have no permission, 
hence it is constructed using the two argument ProtectionDomain 
constructor, which causes ProtectionDomain to not consult the Policy.


However, if a user obtains this ProtectionDomain and asks the Policy for 
the ProtectionDomain's permission's by calling 
Policy::getPermissions(ProtectionDomain), the Policy will return 
AllPermission.


It is generally understood that a ProtectionDomain with a null 
CodeSource is a system ProtectionDomain loaded by the bootstrap ClassLoader.


I propose that innocuous AccessControlContext instead be given a 
ProtectionDomain, with a non-null CodeSource, which has a null URL.  
This is also considered by the Policy to be unprivileged.




 1. Deprecate for removal the CodeSource::implies method.
 2. Give unique ProtectionDomain's with a meaninful CodeSource to
Java modules mapped to the boot loader, rather than using a
Shared ProtectionDomain with a null CodeSource.

    10. Deprecate for removal AccessController::checkPermission and 
AccessControlContext::checkPermission methods.


    11. Undeprecate AccessController, AccessControlContext, 
DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, while 
deprecating for removal methods stated in items above.



To clarify what an *unprivileged* AccessControlContext is:

An instance of AccessControlContext, that contains a single
element array, containing a ProtectionDomain, with a non null
CodeSource, containing a null URL.

Retention of AccessController, AccessControlContext, DomainCombiner 
and SubjectDomainCombiner and Subject::doAs methods.


Stubbing of SecurityManager and Policy, for runtime backward 
compatibility. Update ProtectionDomain::implies method, to *not* 
consult with the Policy.  Note it's possible to get access to the 
ProtectionDomain array contained wi

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

One more proposed change inline:

On 26/06/2021 12:58 pm, Peter Firmstone wrote:


Summary of Proposed Changes:

 1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (Note GuardFactory
should never return null and instead return a no-op Guard that
hotspot can optimize out.
 2. Existing Permission implementations to be obtained using
GuardFactorySpi implementations, until their removal.  Note that
when SecurityManager is stubbed out and Permission implementations
are deprecated for removal, these should no longer be provided by
default, but instead need to be enabled by entries in the
java.security config file, in preparation for their removal.
 3. JDK code, no longer call Permission implementations directly,
instances obtained using GuardFactory, only when enabled in the
java.security configuration file.
 4. Threads (system and virtual) updated to use a singleton
*unprivileged* AccessControlContext, instead of inherited
AccessControlContext, this is more appropriate for Executors, the
original inherited context was designed before Executors were
introduced.
 5. Deprecation for removal of all Permission implementations from the
JDK platform.   The existing implementations of Permission
introduce unnecessary complexity; they lack sufficient flexibility
resulting in a proliferation of Permission grants required in
policy files and some make blocking network calls.
 6. Introduce a system property to change AccessController default
behaviour, disable the stack walk by default, but allow it to be
re-enabled with a system property, replace the stack walk array
result of ProtectionDomains with an *unprivileged*
AccessControlContext, the SubjectDomainCombiner can replace it
with a, AccessControlContext containing a single element array,
containing one ProtectionDomain with Principals.
 7. AccessController::doPrivileged erases the DomainCombiner by
default, deprecate these methods, retain doPrivilegedWithCombiner
methods that preserve the SubjectDomainCombiner.   Developers
should replace their doPrivileged methods with
doPrivilegedWithCombiner
 8. Deprecate for removal the CodeSource::implies method.
 9. Give unique ProtectionDomain's with a meaninful CodeSource to Java
modules mapped to the boot loader, rather than using a Shared
ProtectionDomain with a null CodeSource.

    10. Deprecate for removal AccessController::checkPermission and 
AccessControlContext::checkPermission methods.


    11. Undeprecate AccessController, AccessControlContext, 
DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, while 
deprecating for removal methods stated in items above.



To clarify what an *unprivileged* AccessControlContext is:

An instance of AccessControlContext, that contains a single
element array, containing a ProtectionDomain, with a non null
CodeSource, containing a null URL.

Retention of AccessController, AccessControlContext, DomainCombiner 
and SubjectDomainCombiner and Subject::doAs methods.


Stubbing of SecurityManager and Policy, for runtime backward 
compatibility. Update ProtectionDomain::implies method, to *not* 
consult with the Policy.  Note it's possible to get access to the 
ProtectionDomain array contained within AccessControlContext using a 
DomainCombiner.


This is backward compatible with existing usages of JAAS and least 
painful method of transition for all concerned as well as allowing 
complete flexibility of implementation.


Regards,

Peter Firmstone.

On 25/06/2021 3:59 pm, Peter Firmstone wrote:

Thanks Dalibor,

Would targeting Java 18 be practical?

Also it won't take long to code a prototype, just not sure of the 
process.


Cheers,

Peter.


On 24/06/2021 9:30 pm, Dalibor Topic wrote:

On 24.06.2021 04:24, Peter Firmstone wrote:

Thanks Andrew,

For the simple case, of replacing the SecurityManager stack walk, 
one could use reflection.


Thank you for also confirming that is not possible (or at least 
very unlikely) to add a GuardBuilder to Java 8, the proposal is for 
JDK code to use a provider mechanism, to intercept permission 
checks, so custom authentication layers can be implemented, this 
could be accepted in future versions of Java, but not existing. As 
it is said, there is no harm in asking.


Generally speaking, adding any public APIs to a platform release 
after its specification has been published, is always going to be a 
very tall order involving the JCP, among other things. It's not 
really worth it, when other technical solutions, such as 
multi-release JARs, already exist, that alleviate the necessity.


cheers,
dalibor topic


--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

Summary of Proposed Changes:

1. GuardFactory & GuardFactorySpi to provide hooks for authorization
   checks without SecurityManager or Policy. (Note GuardFactory should
   never return null and instead return a no-op Guard that hotspot can
   optimize out.
2. Existing Permission implementations to be obtained using
   GuardFactorySpi implementations, until their removal.  Note that
   when SecurityManager is stubbed out and Permission implementations
   are deprecated for removal, these should no longer be provided by
   default, but instead need to be enabled by entries in the
   java.security config file, in preparation for their removal.
3. JDK code, no longer call Permission implementations directly,
   instances obtained using GuardFactory, only when enabled in the
   java.security configuration file.
4. Threads (system and virtual) updated to use a singleton
   *unprivileged* AccessControlContext, instead of inherited
   AccessControlContext, this is more appropriate for Executors, the
   original inherited context was designed before Executors were
   introduced.
5. Deprecation for removal of all Permission implementations from the
   JDK platform.   The existing implementations of Permission introduce
   unnecessary complexity; they lack sufficient flexibility resulting
   in a proliferation of Permission grants required in policy files and
   some make blocking network calls.
6. Introduce a system property to change AccessController default
   behaviour, disable the stack walk by default, but allow it to be
   re-enabled with a system property, replace the stack walk array
   result of ProtectionDomains with an *unprivileged*
   AccessControlContext, the SubjectDomainCombiner can replace it with
   a, AccessControlContext containing a single element array,
   containing one ProtectionDomain with Principals.
7. AccessController::doPrivileged erases the DomainCombiner by default,
   deprecate these methods, retain doPrivilegedWithCombiner methods
   that preserve the SubjectDomainCombiner.   Developers should replace
   their doPrivileged methods with doPrivilegedWithCombiner
8. Deprecate for removal the CodeSource::implies method.
9. Give unique ProtectionDomain's with a meaninful CodeSource to Java
   modules mapped to the boot loader, rather than using a Shared
   ProtectionDomain with a null CodeSource.

To clarify what an *unprivileged* AccessControlContext is:

   An instance of AccessControlContext, that contains a single element
   array, containing a ProtectionDomain, with a non null CodeSource,
   containing a null URL.

Retention of AccessController, AccessControlContext, DomainCombiner and 
SubjectDomainCombiner and Subject::doAs methods.


Stubbing of SecurityManager and Policy, for runtime backward 
compatibility. Update ProtectionDomain::implies method, to *not* consult 
with the Policy.  Note it's possible to get access to the 
ProtectionDomain array contained within AccessControlContext using a 
DomainCombiner.


This is backward compatible with existing usages of JAAS and least 
painful method of transition for all concerned as well as allowing 
complete flexibility of implementation.


Regards,

Peter Firmstone.

On 25/06/2021 3:59 pm, Peter Firmstone wrote:

Thanks Dalibor,

Would targeting Java 18 be practical?

Also it won't take long to code a prototype, just not sure of the 
process.


Cheers,

Peter.


On 24/06/2021 9:30 pm, Dalibor Topic wrote:

On 24.06.2021 04:24, Peter Firmstone wrote:

Thanks Andrew,

For the simple case, of replacing the SecurityManager stack walk, 
one could use reflection.


Thank you for also confirming that is not possible (or at least very 
unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK 
code to use a provider mechanism, to intercept permission checks, so 
custom authentication layers can be implemented, this could be 
accepted in future versions of Java, but not existing. As it is 
said, there is no harm in asking.


Generally speaking, adding any public APIs to a platform release 
after its specification has been published, is always going to be a 
very tall order involving the JCP, among other things. It's not 
really worth it, when other technical solutions, such as 
multi-release JARs, already exist, that alleviate the necessity.


cheers,
dalibor topic

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

The more I think about it, allowing Thread to use a singleton immutable 
unprivileged AccessControlContext instead of the inherited context is 
the right thing to do, it achieves the original goal of avoiding 
privilege escalation, limits the the size of the context that needs to 
be checked and allows simple support for virtual threads.   The 
AccessController.doPrivileged method allows code to make privileged actions.


The way to implement it, for compatible transition would be:

1. Implement it first in virtual threads.
2. When stubbing out SecurityManager, change system threads to also use
   the singleton unprivileged context, instead of the inherited
   context, which must be calculated for each thread at creation time.
3. Alternative option to item 2, is to make generic grants in policy
   files for affected threads (which inherited privileged context).

I recently generated some principle of least privilege policy files for 
tests:


https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuretest.policy.new

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new

For the generation of these policy files, a properties file was 
provided, to populate the policy files with properties, to replace local 
and platform specific paths and file names.


Note how many permissions are granted to code and principal's. This 
ensures that other code cannot use the principal's thread for privileged 
escalation, and code cannot perform certain tasks without a logged in 
Subject.


This is how we prevent deserialization (not Java deserialization) of 
untrusted data in our case, we have DeserializationPermission. So not 
only do we ensure there's a logged in Subject, that's providing the 
data, but we are also restricting the code that is allowed to parse 
it.   Our deserialization uses constructors to validate invariants but, 
we still avoid using it to process untrusted data.


One pain point is SocketPermission, which doesn't allow IP Address 
subnet wild cards, hence the use of unlimited IP Address wild cards.  
It's generally preferable not to use domain names in SocketPermission, 
due to blocking DNS calls, personally I'd like to replace that with 
RFC3986 normalization.


Note that the JGDMS SecurityManager and Policy implementations are 
performant and scalable, all hotspots in JGDMS are JDK native methods 
(Socket's basically).   The use of virtual threads, would provide a 
significant scalability improvement for JGDMS.


If we could get the proposed GuardBuilder & GuardBuilderSpi happening 
(so developers are freed from the current Permission implementations) as 
well as the proposed changes to thread AccessControlContext below, we 
would have the best authorization layer available.


We can still stub out SecurityManager and remove the Policy and 
Permission implementations, to reduce the maintenance burden for OpenJDK 
developers.


The reality is, the overall result for us, will be much better, if we 
can retain AccessController and AccessControlContext for the following 
reasons:


1. Allowing grants to be made to code and principals, to prevent
   parsing of untrusted data, while limiting the scope of those grants
   (refer to 3).
2. Preserving current JAAS functionality, to authenticate and secure
   connections.
3. Limiting or preventing viral authorization checks from spreading to
   an excessive number of ProtectionDomains (viral Permissions).   For
   the libraries and JVM code that use doPrivileged will continue to
   function using common API's.
4. To enable developers to implement an authorization layer. While this
   may be a small proportion of overall projects, the projects that do
   are usually significant.

We don't require SecurityManager, a Policy or Permission implementations 
to implement an authorization layer and these components are the 
majority of the maintenance burden for OpenJDK, as far as I can tell at 
least.


Basic components required for effective authorization layer implementations:

1. Guard, GuardBuilder and GuardBuilderSpi (or equivalent).
2. AccessController, AccessControlContext and DomainCombiner (These are
   difficult to re-implement in a Java version compatible manner, and
   re-implementations would not have the benefits of JDK support for
   AccessController.doPrivileged, or Thread context, which limits viral
   authorization checks).
3. ProtectionDomain, CodeSource and Principal
4. JAAS, Subject and LoginModule.
5. GSS-API/Kerberos, JCA, JCE and JSSE.

--
Regards,
 
Peter Firmstone


On 24/06/2021 11:50 am, Peter Firmstone wrote:

Clarification inline below.

On 24/06/2021 11:03 am, Peter Firmstone wrote:

Hi Alan,

It is important to understand the reason for the inherited 
AccessControlContext, in order to consider alternatives.


The motivation for inherited context, was simply to avoid privi

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

Thanks Remi,

We're still building on 8, for CORBA-IIOP stubs, but will look into this 
when we've found an alternative IIOP stub compiler.


--
Regards,
 
Peter


On 23/06/2021 8:02 pm, Remi Forax wrote:

- Mail original -

De: "Andrew Dinn" 
À: "Peter Firmstone" , "discuss" 

Cc: "security-dev" 
Envoyé: Mercredi 23 Juin 2021 11:19:42
Objet: Re: Authorization layer API and low level access checks.
OHi Peter,

n 23/06/2021 04:02, Peter Firmstone wrote:

  1. StackWalker - Can stack walker be back ported to Java 8?

The right place to ask about this is the jdk8u updates project list.
However, you probably don't need to ask there because the answer is
almost certainly going to be a very loud no.

JDK8u is in long term maintenance mode. The goal of the updates project
for that release is to fix security issues and critical bugs *and
nothing else* so that existing deployments remain stable as far as
possible. Except when required to meet those goals backporting of new
functionality is done only under exceptional circumstances.

The only recent examples of new function backports that I am aware of
have involved merging up functionality from downstream releases in order
to 1) unify the platform and 2) enable downstream contributors to help
to maintain a single, standard release i.e. highly exceptional cases
where there was a problem for existing users. Your request, by contrast,
is exactly the sort of case that maintainers are trying to avoid -- it
will introduce change with no gain and the potential of breakage for the
vast majority of users.

If you want to deal with  deployments pre and post removal of the
Authorization support that you currently rely on I suggest you consider
doing that by using a multi-release implementation and package it using
the multi-release jar format. If you don't like the idea of
multi-release jars you can still implement a standard jar format
solution using a provider model. However, you will still need to build
the alternative provider jars using the relevant JDK releases so that
different providers can rely on different JDK capabilities..

Technically, you may not need several JDKs because you can ask javac to behave as if it 
was compiling like a previous JDK using the option "--release" (this option is 
also available with Maven and Gradle).
I believe that compiling as the release 8 will be supported up to Java 23.


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

regards,
Rémi

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

Thanks Andrew,

For the simple case, of replacing the SecurityManager stack walk, one 
could use reflection.


Thank you for also confirming that is not possible (or at least very 
unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK code 
to use a provider mechanism, to intercept permission checks, so custom 
authentication layers can be implemented, this could be accepted in 
future versions of Java, but not existing. As it is said, there is no 
harm in asking.


The advantages of being able to address issues with Permission 
implementations and customise, for example,  by providing a replacement 
for SocketPermission, that doesn't call DNS, and allows wild cards for 
subnets, would be significant for the simplification of authorization.


So developers might hope to be able to implement a significantly 
improved authorization layer for a future version of Java, provided we 
have some basic things like JVM hooks for access checks.


--
Regards,
 
Peter Firmstone


On 23/06/2021 7:19 pm, Andrew Dinn wrote:

OHi Peter,

n 23/06/2021 04:02, Peter Firmstone wrote:

 1. StackWalker - Can stack walker be back ported to Java 8?


The right place to ask about this is the jdk8u updates project list. 
However, you probably don't need to ask there because the answer is 
almost certainly going to be a very loud no.


JDK8u is in long term maintenance mode. The goal of the updates 
project for that release is to fix security issues and critical bugs 
*and nothing else* so that existing deployments remain stable as far 
as possible. Except when required to meet those goals backporting of 
new functionality is done only under exceptional circumstances.


The only recent examples of new function backports that I am aware of 
have involved merging up functionality from downstream releases in 
order to 1) unify the platform and 2) enable downstream contributors 
to help to maintain a single, standard release i.e. highly exceptional 
cases where there was a problem for existing users. Your request, by 
contrast, is exactly the sort of case that maintainers are trying to 
avoid -- it will introduce change with no gain and the potential of 
breakage for the vast majority of users.


If you want to deal with  deployments pre and post removal of the 
Authorization support that you currently rely on I suggest you 
consider doing that by using a multi-release implementation and 
package it using the multi-release jar format. If you don't like the 
idea of multi-release jars you can still implement a standard jar 
format solution using a provider model. However, you will still need 
to build the alternative provider jars using the relevant JDK releases 
so that different providers can rely on different JDK capabilities..


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: Authorization layer API and low level access checks.

[Peter Firmstone]

Clarification inline below.

On 24/06/2021 11:03 am, Peter Firmstone wrote:

Hi Alan,

It is important to understand the reason for the inherited 
AccessControlContext, in order to consider alternatives.


The motivation for inherited context, was simply to avoid privilege 
escalation, prior to Executors.


Whenever a permission check is made, the DomainCombiner, combines the 
inherited context, with the thread's current context, in case there 
are any less privileged domains in the inherited context.


But there is an alternative, higher performance option, that avoids 
privilege escalation for executors as well.


A ProtectionDomain with a null CodeSource has AllPermission, while a 
ProtectionDomain that contains a CodeSource with a null URL has only 
the Permission's given to it when created, or to blanket grant 
statements in policy files.


Rather than inherit context from the calling thread, all threads upon 
creation could be initialized with one shared immutable unprivileged 
AccessControlContext, containing a single element array, with a 
ProtectionDomain, containing a CodeSource with a null URL.


Code cannot assume that calling code is privileged, hence the 
AccessController.doPrivileged method, so an unprivileged context could 
replace system threads inherited context as well.   There will be some 
minor impacts in older code where developers create a system thread 
for cleanup tasks or other things, but nothing that couldn't be worked 
around, until it can be addressed properly. This is an existential 
moment for Java authorization, as a developer with extensive use of 
Java authorization, I would most certainly welcome this change.


This would be a simplification that enhances security.   This is far 
more preferable than an inherited AccessControlContext as it 
eliminates any risk that Executor tasks present, where domains in the 
context that creates Callable or Runnable, may not be in the inherited 
thread context.  JEP 411, presents an opportunity to address it.


A use case:

I would like to use virtual threads, in executors, to make blocking 
secure network connections, so I don't consume too many system 
threads.   When network failures occur, the number of threads created 
increase significantly, as blocked threads waiting on network are no 
longer available to the executor.


All our executor tasks are wrapped, with AccessControlContext, using 
Executors::callable(PrivilegedAction), we do this to capture the 
Subject, and to grant SocketPermission (to Principles and CodeSource) 
to make secure network calls from one node to another.  Across the 
network, the user Subject's Principals are preserved, from the thread 
in the client to the thread in the server during authentication.  
DeserializationPermission is granted to the user Principal's and 
CodeSource in the server, so that the code cannot perform 
deserialization (not to be confused with Java serialization) without 
an authenticated user.   The authenticated user represents the domain 
from which data to be deserialized originates.


Personally I would like to see AccessController and 
AccessControlContext retained, and all threads modified to be 
initialized with a single shared immutable unprivileged 
AccessControlContext, rather than an inherited AccessControlContext in 
system threads and virtual threads that do not support any permissions 
at all.
All threads except bootstrap threads in the JVM, obviously they would 
need to be privileged.


--
Regards,
 
Peter Firmstone

Re: Authorization layer API and low level access checks.

[Peter Firmstone]

Hi Alan,

It is important to understand the reason for the inherited 
AccessControlContext, in order to consider alternatives.


The motivation for inherited context, was simply to avoid privilege 
escalation, prior to Executors.


Whenever a permission check is made, the DomainCombiner, combines the 
inherited context, with the thread's current context, in case there are 
any less privileged domains in the inherited context.


But there is an alternative, higher performance option, that avoids 
privilege escalation for executors as well.


A ProtectionDomain with a null CodeSource has AllPermission, while a 
ProtectionDomain that contains a CodeSource with a null URL has only the 
Permission's given to it when created, or to blanket grant statements in 
policy files.


Rather than inherit context from the calling thread, all threads upon 
creation could be initialized with one shared immutable unprivileged 
AccessControlContext, containing a single element array, with a 
ProtectionDomain, containing a CodeSource with a null URL.


Code cannot assume that calling code is privileged, hence the 
AccessController.doPrivileged method, so an unprivileged context could 
replace system threads inherited context as well.   There will be some 
minor impacts in older code where developers create a system thread for 
cleanup tasks or other things, but nothing that couldn't be worked 
around, until it can be addressed properly. This is an existential 
moment for Java authorization, as a developer with extensive use of Java 
authorization, I would most certainly welcome this change.


This would be a simplification that enhances security.   This is far 
more preferable than an inherited AccessControlContext as it eliminates 
any risk that Executor tasks present, where domains in the context that 
creates Callable or Runnable, may not be in the inherited thread 
context.  JEP 411, presents an opportunity to address it.


A use case:

I would like to use virtual threads, in executors, to make blocking 
secure network connections, so I don't consume too many system 
threads.   When network failures occur, the number of threads created 
increase significantly, as blocked threads waiting on network are no 
longer available to the executor.


All our executor tasks are wrapped, with AccessControlContext, using 
Executors::callable(PrivilegedAction), we do this to capture the 
Subject, and to grant SocketPermission (to Principles and CodeSource) to 
make secure network calls from one node to another.  Across the network, 
the user Subject's Principals are preserved, from the thread in the 
client to the thread in the server during authentication.  
DeserializationPermission is granted to the user Principal's and 
CodeSource in the server, so that the code cannot perform 
deserialization (not to be confused with Java serialization) without an 
authenticated user.   The authenticated user represents the domain from 
which data to be deserialized originates.


Personally I would like to see AccessController and AccessControlContext 
retained, and all threads modified to be initialized with a single 
shared immutable unprivileged AccessControlContext, rather than an 
inherited AccessControlContext in system threads and virtual threads 
that do not support any permissions at all.


--
Regards,
 
Peter Firmstone


On 23/06/2021 4:34 pm, Alan Bateman wrote:

On 23/06/2021 04:02, Peter Firmstone wrote:


Note: I'm not sure how to replace an inherited AccessControlContext 
(with a new implementation based on StackWalker functionality) at 
thread creation time, as it must be created when threads are created, 
possibly by using ThreadFactory everywhere, but this doesn't cover 
all threads. How to cater for virtual threads?


I don't think the inherited AccessControlContext is widely known or 
even clearly specified. In any case, virtual threads do not want to be 
burdened with this field. For now they are specified to not support 
any permissions. The FJ common pool is another example, the threads 
don't have any permissions either (see FJP class description has more 
on that).


-Alan

Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads

[Peter Firmstone]

Thanks Seán,

A good explanation. :)

Solaris was a very good platform for exposing and debugging race 
conditions, of course we have very good static analysis now.


Regards,

Peter.

On 23/06/2021 5:10 pm, Seán Coffey wrote:

Thank for the feedback Peter. Comments inline.

On 22/06/2021 22:40, Peter Firmstone wrote:

Was ever to run with SecurityManager?
I found the issue while porting to jdk8u where Solaris uses a 
configuration file with the SunPKCS11 Provider by default - We have 
tests to register Providers while SecurityManager is in place. This 
failed for SunPKCS11.


When you see an AccessControlException, I'd recommend setting the 
following security debug property, so you can capture the 
ProtectionDomain that failed the access check: 
-Djava.security.debug=access:failure  Clearly there's a 
ProtectionDomain on the calling threads stack that doesn't have the 
necessary permission.  If you knew which one it was, you could just 
grant it java.lang.RuntimePermission "setContextClassLoader" 
permission in the policy file.
Yes - that was one of my first actions. [1]. The jdk.crypto.cryptoki 
ProtectionDomain lacks the permission and rightly so IMO. The default 
policy doesn't grant "setContextClassLoader" permission to any JDK 
module. It's not required when we use InnocuousThread.


In NativeResourceCleaner the original constructor is setting the 
Context ClassLoader of the calling thread to null, prior to calling 
the Thread superclass constructor, so that both the calling thread 
and new thread will nave a null context ClassLoader.  In your new 
implementation, you are asserting the context class loader of the 
created thread is null, without setting the context ClassLoader of 
the original calling thread, is that the intended behaviour?


Alternatively you could set the context ClassLoader of the calling 
thread to null using a PrivilegedAction, prior to creating the new 
thread and restore it?
Use of InnocuousThread is made in various JDK classes for similar 
purpose where daemon threads need to be run with limited privilege. 
Similar use seen in networking and ldap classes.




If the original intent was to set the context ClassLoader of the new 
thread to null, then why not just do that, rather than use an assertion?
InnocuousThread sets this to null. The assert is just a belt and 
braces approach which is a useful check during test runs. Again, 
similar approach done in other JDK libraries.


If assertions are not enabled it may run with a non null context 
ClassLoader?   What are the consequences?  It appears to me, the fix 
has created a bigger problem, rather than fixed it.  Just my 2 cents.


see above. We shouldn't have an issue. A non-null classloader would 
lead to classloader memory leak in some environments.


regards,
Sean.



We use SecurityManager by default following principles of least 
privilege (only the code paths we need to execute), and the original 
reported bug is a non problem for us, we would capture the missing 
permission and grant it, these are permission grants for Java 16:


grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";

};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission 
"putProviderProperty.SunEC";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.x509";

};

Good call making NativeResourceCleaner implement Runnable instead of 
extending Thread though.



[1]

access: domain that failed ProtectionDomain (jrt:/jdk.crypto.cryptoki 
)

 jdk.internal.loader.ClassLoaders$PlatformClassLoader@5433274e
 
 java.security.Permissions@7006c658 (
 ("java.io.FilePermission" "<>" "read")
 ("java.net.SocketPermission" "localhost:0" "listen,resolve")
 ("java.security.SecurityPermission" "clearProviderProperties.*")
 ("java.security.SecurityPermission" 
"getProperty.auth.login.defaultCallbackHandler")

 ("java.security.SecurityPermission" "putProviderProperty.*")
 ("java.security.SecurityPermission" "authProvider.*")
 ("java.security.SecurityPermission" "removeProviderProperty.*")
 ("java.util.PropertyPermission" "java.specification.version" "read")

Authorization layer API and low level access checks.

[Peter Firmstone]

Java developers such as myself need a light weight API that allows 
developers to continue to support authorization and access controls, 
without dictating how that should be implemented or whether these 
controls are fine grained, course grained, based solely on user 
authorization or also includes code authorization.


SecurityManager has been deprecated, we need to commence removal of 
dependencies on deprecated Java API's, however we are unable to make a 
decision on how to proceed without understanding the level of support 
that OpenJDK will provide for an authorization layer in future. (If this 
is zero, we at least need to know).


Currently there is no such API that allows developers who require an 
authorization layer to continue to supporting Java 8 as well future 
versions Java with one development codebase.  It's a non goal of this to 
debate the need for cross version support.   I simply wish to open 
discussions on alternatives and whether OpenJDK is considering them.


SecurityManager API low level functionality replacements:

1. StackWalker - Can stack walker be back ported to Java 8?
2. Permission checks - Can we have low level Guard service hooks to
   replace existing permission checks?

Note: I'm not sure how to replace an inherited AccessControlContext 
(with a new implementation based on StackWalker functionality) at thread 
creation time, as it must be created when threads are created, possibly 
by using ThreadFactory everywhere, but this doesn't cover all threads.  
How to cater for virtual threads?


For replacement of permission checks, I propose using a Guard service 
authorization API (feel free to propose alternatives).


The proposed authorization layer API would utilize the existing Provider 
Service mechanism to register authorization layer hooks, for use in 
permission checks by JDK code, and library code that implements their 
own Permission's:


GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");

Guard createClassLoader = 
runtimeGuardFactory.orders("createClassLoader", null);


// Permission check

createClassLoader.check();

Guard exitVM = runtimeGuardFactory.orders("exitVM", null);

exitVM.check();


GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");

// Permission check
socketGuardFactory.orders(host, action).check();

GuardFactory fileGuardFactory = GuardFactory.getInstance("FILE");

fileGuardFactory.orders(path, actions).check();


Guard service hooks, are based on existing Permission types (independent 
instances to avoid circular deadlocks), developers only need implement 
those relevant to them and may only use checks for users if they wish:


"AWT"
 "FILE"
 "SERIALIZABLE"
 "MANAGEMENT"
 "REFLECT"
 "RUNTIME"
 "NET"
 "SOCKET"
 "URL"
 "FILE-LINK"
 "SECURITY"
 "SQL"
 "LOGGING"
 "PROPERTY"
 "MBEAN"
 "MBEAN-SERVER"
 "MBEAN-TRUST"
 "SUBJECT-DELEGATION"
 "TLS"
 "AUTH"
 "KERBEROS-DELEGATION"
 "KERBEROS-SERVICE"
 "PRIVATE-CREDENTIAL"
 "AUDIO"
 "JAXB"
 "WEB-SERVICE"

I would like to suggest adding a new provider type:

"PARSE-DATA" - To be called by any code about to parse data, eg 
deserialization, XML, JSON, SQL, etc.   The use case for this is for 
servers to grant it to authenticated users (user supplied input data), 
so that it can only be performed following user authentication.


Existing Permission implementations

--
Regards,
 
Peter Firmstone

Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads

[Peter Firmstone]

Was ever to run with SecurityManager?

When you see an AccessControlException, I'd recommend setting the 
following security debug property, so you can capture the 
ProtectionDomain that failed the access check: 
-Djava.security.debug=access:failure  Clearly there's a ProtectionDomain 
on the calling threads stack that doesn't have the necessary 
permission.  If you knew which one it was, you could just grant it 
java.lang.RuntimePermission "setContextClassLoader" permission in the 
policy file.


In NativeResourceCleaner the original constructor is setting the Context 
ClassLoader of the calling thread to null, prior to calling the Thread 
superclass constructor, so that both the calling thread and new thread 
will nave a null context ClassLoader.  In your new implementation, you 
are asserting the context class loader of the created thread is null, 
without setting the context ClassLoader of the original calling thread, 
is that the intended behaviour?


Alternatively you could set the context ClassLoader of the calling 
thread to null using a PrivilegedAction, prior to creating the new 
thread and restore it?


If the original intent was to set the context ClassLoader of the new 
thread to null, then why not just do that, rather than use an assertion?


If assertions are not enabled it may run with a non null context 
ClassLoader?   What are the consequences?  It appears to me, the fix has 
created a bigger problem, rather than fixed it.  Just my 2 cents.


We use SecurityManager by default following principles of least 
privilege (only the code paths we need to execute), and the original 
reported bug is a non problem for us, we would capture the missing 
permission and grant it, these are permission grants for Java 16:


grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";

};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission 
"putProviderProperty.SunEC";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.x509";

};

Good call making NativeResourceCleaner implement Runnable instead of extending 
Thread though.

--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.


On 22/06/2021 11:32 pm, Sean Coffey wrote:

Sufficient permissions missing if this code was ever to run with 
SecurityManager.

Cleanest approach appears to be use of InnocuousThread to create the 
cleaner/poller threads.
Test case coverage extended to cover the SecurityManager scenario.

Reviewer request: @valeriepeng

-

Commit messages:
  - 8269034: AccessControlException for SunPKCS11 daemon threads

Changes: https://git.openjdk.java.net/jdk17/pull/117/files
  Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=117=00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8269034
   Stats: 112 lines in 5 files changed: 73 ins; 17 del; 22 mod
   Patch: https://git.openjdk.java.net/jdk17/pull/117.diff
   Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117

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

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Firmstone]

On 16/06/2021 11:18 pm, David Lloyd wrote:

There are already issues with Permission implementations, take for
example SocketPermission, it consults DNS and it isn't possible to enter
a range of IP addresses (such as the local subnet, and a list of public
IP addresses), for now, every single IP address must be entered and this
isn't practical.   The proposed API would allow us to re-implement
SocketPermission functionality, as well as other Permission implementations.

Sure, this would be nice to clean up.



What the above example enhances:

 * Generation of policy files during integration testing.
 * Specifying Properties, to replace local information contained in URL
   and file paths, for later policy expansion.
 * In this specific case, I could substitute an IP address with a
   property that specified an allowed subnet mask, this would
   automatically expand the SocketPermission to the local subnet, and
   it would shrink the size of the generated policy file by eliminating
   other SocketPermission grants to IP addresses on the subnet.

--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Firmstone]

On 18/06/2021 1:18 pm, Peter Firmstone wrote:


On 16/06/2021 11:18 pm, David Lloyd wrote:

On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
 wrote:


Permission references can be replaced with Guard references (which
Permissions are instances of).

I guess you've got something fairly complex in mind, could you give
some practical examples of how this would work?



The same service provider mechanism encryption uses.  So 
implementation may utilize authorization access check points without 
any dependencies on current SecurityManager, Policy or Permission API's.



Eg GuardFactorySpi




It's completely up to the implementation to determine how to manage.





The Permission implementations of Guard::check call SecurityManager, so
checks will continue working as expected, but it allows us to intercept
them and do something different.

What do you envision these checks looking like?  Where would the JDK
find these Guard instances?



GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");

Guard localhostConnectAccept = socketGuardFactory.orders("localhost", 
"connect,accept");


// Permission check

localHostConnectAccept.check();



GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");

Guard createClassLoader = 
runtimeGuardFactory.orders("createClassLoader", null);


// Permission check

createClassLoader.check();


--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Firmstone]

On 16/06/2021 11:18 pm, David Lloyd wrote:

On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
 wrote:


Permission references can be replaced with Guard references (which
Permissions are instances of).

I guess you've got something fairly complex in mind, could you give
some practical examples of how this would work?



The same service provider mechanism encryption uses.  So implementation 
may utilize authorization access check points without any dependencies 
on current SecurityManager, Policy or Permission API's.


It's completely up to the implementation to determine how to manage.





The Permission implementations of Guard::check call SecurityManager, so
checks will continue working as expected, but it allows us to intercept
them and do something different.

What do you envision these checks looking like?  Where would the JDK
find these Guard instances?



GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");

Guard localhostConnectAccept = socketGuardFactory.orders("localhost", 
"connect,accept");


// Permission check

localHostConnectAccept.check();



GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");

Guard createClassLoader = 
runtimeGuardFactory.orders("createClassLoader", null);


// Permission check

createClassLoader.check();

--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: blizzard of deprecation warnings related to JEP 411

[Peter Firmstone]

Hi Rick

This is dependant on OpenJDK creating hooks in JVM code for existing 
permission's without depending existing Security infrastructure.


The major components can be found here, also available on Maven:

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/SecurityContext.java

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

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

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java

Regards,

Peter.

On 17/06/2021 1:00 am, Rick Hillegas wrote:
Thanks, Peter. Derby supports a couple authorization mechanisms, the 
most important one being the role-based SQL Standard GRANT/REVOKE 
commands (see 
https://db.apache.org/derby/docs/10.15/security/csecauthorization.html). 
I'm afraid that my old eyes didn't see a link to your authorization 
libraries in your message.


On 6/15/21 5:23 PM, Peter Firmstone wrote:

Rick,

Out of curiosity, does Apache Derby have a need for an Authorization 
layer?


We have tooling to generate our policy files, which simplifies the 
process a lot, we also have highly scalable and performant 
SecurityManager and Policy implementations which are compatible with 
standard Java policy files.


This is available under an AL2.0 license.

I'm hoping that OpenJDK will create some hooks for permission checks, 
so that we can continue to provide an authorization layer for Java, 
following JEP 411.


I'll be using StackWalker to reproduce AccessController's stack 
walk.   We also have existing classes which wrap 
AccessControlContext, so we would use ThreadLocal's to preserve subject.





--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: blizzard of deprecation warnings related to JEP 411

[Peter Firmstone]

Rick,

Out of curiosity, does Apache Derby have a need for an Authorization layer?

We have tooling to generate our policy files, which simplifies the 
process a lot, we also have highly scalable and performant 
SecurityManager and Policy implementations which are compatible with 
standard Java policy files.


This is available under an AL2.0 license.

I'm hoping that OpenJDK will create some hooks for permission checks, so 
that we can continue to provide an authorization layer for Java, 
following JEP 411.


I'll be using StackWalker to reproduce AccessController's stack walk.   
We also have existing classes which wrap AccessControlContext, so we 
would use ThreadLocal's to preserve subject.


--
Regards,
 
Peter.


On 16/06/2021 1:56 am, Alan Bateman wrote:

On 15/06/2021 15:10, Rick Hillegas wrote:

:

When I tried to build Derby with the Rampdown Phase One build of open 
JDK 17 (17-ea+26-2439), I saw many warnings related to the 
deprecation of Security Manager classes and methods, undoubtedly the 
consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby, 
like Tomcat, embraced the Security Manager early on. Permissions 
checks were rototilled across the whole code base and our 
distributions ship with several template policy files, which we 
encourage users to customize for their environments. The "Configuring 
Java Security" section of our Security Guide explains how to do this 
(https://db.apache.org/derby/docs/10.15/security/index.html).


My build only reported the first 100 warnings. It is likely that 
there are many more.


Yes, JEP 411 deprecates a number of APIs for future removal. There 
probably isn't much to do right now except to be aware that the APIs 
are earmarked for removal in some future release. I've no doubt there 
will be another JEP when that time comes. I assume you know about 
@SuppressWarnings("removal"), which you can use to suppress the 
warnings for now. The JDK usages of these APIs are using 
SuppressWarnings as the JDK is compiled with -Xlint set to made 
warnings fatal.


-Alan

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Firmstone]

On 14/06/2021 9:34 pm, Rafael Winterhalter wrote:

Why not add the property once this is the case, though?
As it is now, I read the 'forRemoval' property to indicate a problem 
that should be instantly addressed.



I too suggested and support this approach.


With Java 8 being a common baseline for libraries and the version 
being supported until (at least) 2030, I don't see how this removal 
would have a low impact within the next decade, if ever. Shouldn't the 
property be set if the removal is within reach? To some degree, I 
would expect that any deprecated API could be removed once it is no 
longer used.


As it is now, library maintainers face the choice of breaking their 
support for current users that are on Java 8/11 and rely on the 
security manager, or to remove their support to accommodate a Java 
release that might be many years in the future.



For this reason, I'm proposing a minimal change allowing us to implement 
Guard::check hooks at existing check points within the JVM using the 
security provider mechanism that can be back-ported and supported on all 
LTS releases, without any new Java API's.


We require authorization layer functionality, I will be implementing it, 
and it will be freely available under an AL2.0 license.


It would be nice to keep AccessController and AccessControlContext and 
use a property to enable or disable the stack walk for those who don't 
require it, however they are now marked for removal, so I'll be looking 
at using wrapper classes around them, so their implementations can be 
replaced at a later data.


Our current implementation is high scaling with minimal performance 
impact, however I can't make any promises regarding future performance, 
but hopefully it will come to be as performant as our current 
implementation.


Regards, Peter.

For my part, supporting the security manager seems to be the right 
choice as things stand today.
Over the years, I would expect that fewer and fewer people rely on the 
security manager, where this balance might shift. I would hope that 
the 'forRemoval' property would serve as an indicator at that time to 
tell library maintainers that usage of the security manager has 
decreased so much that it is time to remove the library support, too. 
I see the reason for a strong signal, deprecation already is such a 
signal, but if you give the full blow today, it is no longer available 
in the future where it might be more relevant to give.


Am Mo., 14. Juni 2021 um 11:26 Uhr schrieb Ron Pressler 
mailto:ron.press...@oracle.com>>:


The JEP addresses this:

> In future JDK releases, we will degrade the Security Manager
APIs so that they
remain in place but have limited or no functionality. ... This
will allow libraries
that support the Security Manager and were compiled against
previous Java releases
to continue to work without change or even recompilation. We
expect to remove the
APIs once the compatibility risk of doing so declines to an
acceptable level.

If your question is, when only few codebases will refer to the API
and the
compatibility impact is low enough for it to be removed, what if
some of those
few libraries still want to support versions prior to the removal,
the answer is
the same as with all removals (MR-JARs, or multiple artefacts). By
definition,
the impact of complete removal when the impact is low, would be low.

— Ron

> On 14 Jun 2021, at 09:38, Rafael Winterhalter
mailto:rafael@gmail.com>> wrote:
>
> One example for a currently necessary "doPrivileged" are Java
agents where
> a class loading triggers agent code where the agent shares the
stack with
> any code that loads a class for the first time. Otherwise, Byte
Buddy wraps
> anything that might require privileges as privileged action to allow
> setting a policy that gives Byte Buddy for example access to
class loaders,
> system properties or other things that the security manager
currently
> checks. There's many uses of the security manager throughout the
library,
> in the spirit of the API's invention.
>
> I could, of course, rip this code out of the library. But this
would make
> it impossible for users that choose to use the functionality for
now to
> update their dependency. This would certainly hinder a smooth
transition as
> library maintainers will always have people drag at both ends of
the JDK
> version range. After all, Java 8 is supported for another decade.
> Multi-release jars are neither a feasible option. They are not
globally
> supported by all class loaders, and would require me to add a
copy of an
> adjusted class file for any Java version prior to the removal
version or
> upwards from there. I don't think that this should be addressed
by tooling
> if keeping deprecated skeletons of the API can so 

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Firmstone]

On 15/06/2021 2:23 am, David Lloyd wrote:


On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
 wrote:

  1. Develop authorization layer security provider services in OpenJDK,
 back port it to Java 8 and Java 11 (these provide most of the
 utilised functionality of SecurityManager, allowing developers to
 only implement those which they need, without enabling
 SecurityManager and editing policy files).
  2. Remove SecurityManager, Policy and Policy provider in OpenJDK 19.

The SecurityManager class itself already is *exactly* an authorization
provider.  I don't think it makes sense to consider removing the
security manager class to replace it with something that has basically
exactly the same API


Logic behind this choice:

SecurityManager depends on Permission, currently there are Permission 
checks throughout the JVM, however Permission implementation classes 
will be removed, although the Permission class itself won't be.


Permission references can be replaced with Guard references (which 
Permissions are instances of).


The Permission implementations of Guard::check call SecurityManager, so 
checks will continue working as expected, but it allows us to intercept 
them and do something different.


By replacing Permission references with Guard, it allows us to implement 
our own checks in these locations, and OpenJDK doesn't need to maintain 
Permission instances, and or, we don't need to make use of unmaintained 
Permission implementations.


There are already issues with Permission implementations, take for 
example SocketPermission, it consults DNS and it isn't possible to enter 
a range of IP addresses (such as the local subnet, and a list of public 
IP addresses), for now, every single IP address must be entered and this 
isn't practical.   The proposed API would allow us to re-implement 
SocketPermission functionality, as well as other Permission implementations.


This proposal also allows every existing component of the SM 
architecture to be removed, while retaining the most important 
component, the checks themselves, such that you or I or anyone else for 
that matter can re-implement the functionality of SM.


SM and friends will be removed eventually, so now is our opportunity to 
get something in place that has minimal impact on OpenJDK maintenance, 
that will remain.



(specifically, a single method for each general
authorization check that can be called without constructing any new
objects, if and only if the authorization provider is installed).  See
my other proposal where, post-"removal", SecurityManager (the class)
is retained but made abstract (and sans a few methods).  All of the
existing code which performs authorization checks would be retained
and the problem solved in essentially the way you're describing, just
using existing APIs.

The security manager implementation itself can implement any kind of
authorization behavior whatsoever, based mainly on the Permission
types (which work just fine for this purpose, and anyway are already
retained by the current JEP).  Policy and its supporting classes are
completely unnecessary for implementing a security policy.  In fact,
this is the case today already.

On Mon, Jun 14, 2021 at 12:57 AM Alan Bateman  wrote:

AccessController::doPriv just runs the action.

TBH this should have always been the case.  Implementation-wise, if
one were constructing an access control context based on stack
walking, one would stop at points where `AccessController` is on the
stack (which is easily determinable) to do special work on assembling
the access control context based on the method called at that frame.


Yes, one can do that, but these classes will also eventually be removed.

--

Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Firmstone]

On 14/06/2021 6:37 pm, Alan Bateman wrote:


There are some libraries where the maintainers have put effort into 
working with a SM.


Yes, I am one of them, very much so.

At first it's a shock, but the show must go on, it could be an 
opportunity to address some long standing issues also.


If Permission implementations are unmaintained, we are better off 
without them too and re implementing our own.   It doesn't matter what 
they change to, I can generate my policy files.


AccessController, AccessControlContext and DomainController are bigger 
fish, which will take longer, personally I wouldn't remove these 
classes, but it's not my choice.


--
Regards,
 
Peter.

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Firmstone]

Binary compatibility only?

Security.getSecurityManager() always returns null.

Security.setSecurityManager() always throws a SecurityException 
(compatible because existing SecurityManager is allowed to prevent the 
call from succeeding).


SecurityManager constructor always throws a SecurityException 
(compatible because existing SecurityManager is allowed to prevent the 
call from succeeding).


Remove all methods from SecurityManager, no instances will be created, 
so methods will not be resolved, still binary compatible.


For Policy, retain methods and constructor, throwing appropriate 
exceptions, eg SecurityException or NoSuchAlgorithmException. Note that 
constructor will throw no exception, the exception will be thrown when  
attempting to set Policy.


Remove PolicyFile implementation.

Leave PolicySPI as is, but don't load them.

The first step would be to provide low level JDK hooks that allow for 
equivalent functionality to be implemented, back-porting to all long 
term releases, while leaving SecurityManager unchanged.


Then change SecurityManager prior to next LTS version (Java 23) to 
binary compatible only.  Then prior to the next LTS version (Java 29), 
remove it.


Maintained software will have had plenty of time to update and be 
compatible across all supported Java releases, provided appropriate JDK 
hooks are provided, only unmaintained software will still require it and 
unmaintained software will still run on unmaintained Java releases in 
VM's with unmaintained OS's.


Peter.

On 14/06/2021 6:37 pm, Alan Bateman wrote:

On 14/06/2021 08:35, Peter Firmstone wrote:


I wouldn't want to see SecurityManager and Policy be neutralized, 
it's better to remove it and fail early so people update their 
software, there's a risk they may update without realizing it's no 
longer fully functional.   Get rid of the baggage so people can start 
fresh with better practices.


I think the context for the question is libraries that want to be able 
to compile to an older JDK release and work with a very wide range of 
JDK releases.


Many libraries do not play well with a SM. They don't execute actions 
that require permission checks in privileged blocks and will often 
need to be granted AllPermission. This may have knock on impact to the 
components that call into these libraries, maybe they end up needing 
to be  granted AllPermission too. Add callbacks or hand-off between 
threads to the picture and it can become farcical. If the library code 
isn't calling System.getSM or invoking AccessController.doPrivileged 
then it probably won't care if these APIs are degraded or removed.


There are some libraries where the maintainers have put effort into 
working with a SM. Code in the library may use System.getSM, or doPriv 
or limited-doPriv. It may document the permissions that it requires 
and be helpful to someone assembling an application and creating its 
policy file. This JEP is mildly disruptive in that there will be 
warnings at compile-time or testing JDK 17+. If some future JDK 
releases degrades some of these APIs then it may be a bit more 
disruptive, maybe tests that try to set a SM will fail or need to be 
skipped. It might be that a library uses an exotic API that doesn't 
degrade in a sensible way and maybe that will be a bit more 
disruptive. Further out again, if the APIs are actually removed then 
it will be disruptive for libraries that want to support the 
possibility of being deployed with a SM on an older release. That may 
require some refactoring and the use of a MR-JAR as Remi mentioned.


-Alan

Low level hooks in JDK for permission checks.

[Peter Firmstone]

Making things clearer if I can:

Some thoughts on hooks:

 * Utilize java.security.Provider, so as not to expose jdk
   implementation code.  Eg: a module declaration or
   META-INF/services/java.security.Provider to obtain relevant
   instances of java.security.Guard, where Permission implementation
   types are currently used.
 * Allow existing Permission classes to remain backward compatible,
   declare them as services, so that SecurityManager can be degraded as
   planned and Permission implementations can be gradually removed as
   planned. (Removes dependencies on Permission instance types).
 * Guard implementation's are typically required to have a constructor
   with two String arguments, (String name, String actions), can be
   passed as new String[]{ name, actions} constructor parameter to
   java.security.Provider.Service::newInstance.
 * Service must implement Guard interface, with Guard::check method
   (current Permission implementations implement this method and call
   System.getSecurityManager).
 * Doesn't depend on Permission or any existing implementation classes,
   completely customizable by the service implementation.
 * Application developers can also implement hooks using this service.
 * Using security provider avoids deadlock during Provider
   initialization, it must be listed as a provider in the java.security
   file or if security.overridePropertiesFile=true and
   -Djava.security.properties=file://path/additional.security defines
   providers, which would be useful for testing.

Break up guard service providers into current Permission types 
(independent instances to avoid circular deadlocks), developers only 
need implement those relevant to them and may only use checks for users 
if they wish:


"AWT"
"FILE"
"SERIALIZABLE"
"MANAGEMENT"
"REFLECT"
"RUNTIME"
"NET"
"SOCKET"
"URL"
"FILE-LINK"
"SECURITY"
"SQL"
"LOGGING"
"PROPERTY"
"MBEAN"
"MBEAN-SERVER"
"MBEAN-TRUST"
"SUBJECT-DELEGATION"
"TLS"
"AUTH"
"KERBEROS-DELEGATION"
"KERBEROS-SERVICE"
"PRIVATE-CREDENTIAL"
"AUDIO"
"JAXB"
"WEB-SERVICE"

I would like to suggest adding a new provider type:

"PARSE-DATA" - To be called by any code about to parse data, eg 
deserialization, XML, JSON, SQL, etc.  Granted to users, so that it can 
only be performed after authentication.


--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Firmstone]

intuitive to a lot of developers.

Therefore, my question is: should SecurityManager, AccessController 
and the
Policy APIs really be deprecated for removal? Rather, I think that 
the APIs

should be deprecated, but be retained with stubbed implementations.
System.getSecurityMananger would then always return null.
System.setSecurityManager on the other hand could be deprecated for
removal. This way, existing code could continue to work as if the 
security
manager is not active, which already is the common scenario and would 
not

cause any disruption at the small price of keeping a handful of some
stubbed classes.

Thanks for advice on how this is intended to be handled by library
developers like me.
Best regards, Rafael



--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Fwd: Low level hooks in JDK for instrumentation of permission checks.

[Peter Firmstone]

Forgot to cc.

 Forwarded Message 
Subject: 	Re: Low level hooks in JDK for instrumentation of permission 
checks.

Date:   Mon, 14 Jun 2021 15:13:15 +1000
From:   Peter Firmstone 
To: jdk-...@openjdk.java.net



Clarification, utilize java.security.Provider.

So this might use a module declaration or 
META-INF/services/java.security.Provider, sorry got muddled with typical 
ServiceLoader usage below.


The reason for choosing Provider is that it allows constructor 
parameters, it's also security related and can require code signing, not 
sure if that should be a requirement.


Another reason for using security provider is to avoid deadlock during 
Provider initialization, it must be listed as a provider in the 
java.security file or if security.overridePropertiesFile=true and 
-Djava.security.properties=file://path/additional.security defines 
providers, which would be useful for testing.


Dynamic loading a provider using Security.addProvider or 
insertProviderAt causes security checks, each Guard::check call would 
try to initiate "SECURITY" Provider loading causing deadlock.  To avoid 
deadlock at the very least the "SECURITY" and "PROPERTY" 
java.security.Guard services would need to be loaded by java.security at 
startup.


grant codebase "jrt:/java.xml.crypto"
{
    permission java.util.PropertyPermission 
"java.specification.version", "read";
    permission java.security.SecurityPermission 
"putProviderProperty.XMLDSig";

};

Need to be careful with loading and recursive permission checks, it's ok 
if a permission check fires off permission checks that cause loading of 
other providers, we just can't ask the provider that is being 
dynamically loaded to perform permission checks on itself, or any 
circular relationship between providers.


Basically it's good to have separate providers for each permission type 
as it helps avoid deadlocks.


grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";

};

On 14/06/2021 9:56 am, Peter Firmstone wrote:

Some thoughts on hooks:

 * Utilize the Service Provider API, so as not to expose jdk
   implementation code.  META-INF/services/java.security.Guard
 * Allow existing Permission classes to remain backward compatible,
   declare them as services, so that SecurityManager can be degraded as
   planned and these services are gradually removed. (Removes
   dependencies on Permission instance types).
 * Guard implementation is required to have a constructor with two
   String arguments, (String name, String actions).
 * Service must implement Guard interface.
 * Doesn't depend on Permission or any existing implementation classes,
   completely customizable by the service implementation.
 * Application developers can also implement hooks using this service.

Break up guard service providers into current Permission types:

"AWT"
"FILE"
"SERIALIZABLE"
"MANAGEMENT"
"REFLECT"
"RUNTIME"
"NET"
"SOCKET"
"URL"
"FILE-LINK"
"SECURITY"
"SQL"
"LOGGING"
"PROPERTY"
"MBEAN"
"MBEAN-SERVER"
"MBEAN-TRUST"
"SUBJECT-DELEGATION"
"TLS"
"AUTH"
"KERBEROS-DELEGATION"
"KERBEROS-SERVICE"
"PRIVATE-CREDENTIAL"
"AUDIO"
"JAXB"
"WEB-SERVICE"

I would like to suggest adding a new provider type:

"PARSE-DATA" - To be called by any code about to parse data, eg 
deserialization, XML, JSON, SQL, etc.  Granted to users, so that it 
can only be performed after authentication.



--
Regards,
 Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.

Re: Low level hooks in JDK for instrumentation of permission checks.

[Peter Firmstone]

Some thoughts on hooks:

 * Utilize the Service Provider API, so as not to expose jdk
   implementation code.  META-INF/services/java.security.Guard
 * Allow existing Permission classes to remain backward compatible,
   declare them as services, so that SecurityManager can be degraded as
   planned and these services are gradually removed. (Removes
   dependencies on Permission instance types).
 * Guard implementation is required to have a constructor with two
   String arguments, (String name, String actions).
 * Service must implement Guard interface.
 * Doesn't depend on Permission or any existing implementation classes,
   completely customizable by the service implementation.
 * Application developers can also implement hooks using this service.

Break up guard service providers into current Permission types:

"AWT"
"FILE"
"SERIALIZABLE"
"MANAGEMENT"
"REFLECT"
"RUNTIME"
"NET"
"SOCKET"
"URL"
"FILE-LINK"
"SECURITY"
"SQL"
"LOGGING"
"PROPERTY"
"MBEAN"
"MBEAN-SERVER"
"MBEAN-TRUST"
"SUBJECT-DELEGATION"
"TLS"
"AUTH"
"KERBEROS-DELEGATION"
"KERBEROS-SERVICE"
"PRIVATE-CREDENTIAL"
"AUDIO"
"JAXB"
"WEB-SERVICE"

I would like to suggest adding a new provider type:

"PARSE-DATA" - To be called by any code about to parse data, eg 
deserialization, XML, JSON, SQL, etc.  Granted to users, so that it can 
only be performed after authentication.


--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.





On 13/06/2021 8:34 pm, Peter Firmstone wrote:

Thanks Alan,

I've been thinking that it may be preferable to have hooks that 
allowed us to inject our own permission checks, rather than retaining 
existing permission checks.


An implementation can override Guard::check without requiring a 
provider mechanism.


The other advantage is the ability to customize Permission 
implementations, such as allowing address ranges in a SocketPermission 
implementation and not consulting DNS to resolve host names.


Cheers,

Peter.


On 10/06/2021 11:55 pm, Alan Bateman wrote:

On 10/06/2021 07:40, Peter Firmstone wrote:


Just a quick question, would it be possible that some JFR hooks 
might also be useable for an authorisation layer?



JFR events can't be used to intercept/veto operations, assuming that 
is what you are asking. However, it might be that JFR events are 
monitored as part of some overall security approach that takes into 
account events recorded for health, performance, or troubleshooting 
purposes.


-Alan

Re: Low level hooks in JDK for instrumentation of permission checks.

[Peter Firmstone]

Thanks Alan,

I've been thinking that it may be preferable to have hooks that allowed 
us to inject our own permission checks, rather than retaining existing 
permission checks.


An implementation can override Guard::check without requiring a provider 
mechanism.


The other advantage is the ability to customize Permission 
implementations, such as allowing address ranges in a SocketPermission 
implementation and not consulting DNS to resolve host names.


Cheers,

Peter.


On 10/06/2021 11:55 pm, Alan Bateman wrote:

On 10/06/2021 07:40, Peter Firmstone wrote:


Just a quick question, would it be possible that some JFR hooks might 
also be useable for an authorisation layer?



JFR events can't be used to intercept/veto operations, assuming that 
is what you are asking. However, it might be that JFR events are 
monitored as part of some overall security approach that takes into 
account events recorded for health, performance, or troubleshooting 
purposes.


-Alan


--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

JEP 411: Updates to alternatives

[Peter Firmstone]

Noticing the updates made to JEP 411 Alternatives, I think I might have 
a minimalist alternative, you may find interesting:


Remove:

1. SecurityManager
2. Policy provider and implementation
3. Permission checks in JDK code addressed by improvements to
   encapsulation, eg RuntimePermission "access class in package" and 
   ReflectPermission, these are no longer necessary, however I would
   recommend retaining checks at System::getProperty and setProperty,
   as these may contain security sensitive information (eg keystore and
   truststore).
4. doPrivileged calls within the JVM other than those which preserve
   context across threads, most permissions that "leak" are addressed
   at #3 above, and POLP tooling can capture other permissions.  It
   would appear that doPrivileged is more appropriate for application
   code, rather than JDK code.
5. I'm not sure about removing doPrivileged calls intended to preserve
   context within OpenJDK.

Changes (improvements):

1. Make Guard::check a default method, that delegates to a provider,
   with a single method (eg Authority::confirm(Guard)) that does
   nothing by default.  Remove all implementing instances of
   Permission::check. (this could be backported easily).
   SecurityManager methods are just permission checks, existing use
   cases of SecurityManager can be supported with this one method.  
   This could be back ported to Java 8, so libraries that currently
   support all supported Java versions can continue to do so.  All
   calls to SecurityManager methods in JDK code can be replaced by the
   corresponding permission check.
2. Add permission checks to data parsers (eg deserialization), this
   allows implementations to grant these permissions only to users, if
   there is not an authenticated user, then the data received by the
   parser cannot be trusted.
3. "Modules that are mapped to the boot loader get a unique
   ProtectionDomain that includes a useful code source rather than
   using a "shared" PD."   This allows permission to be granted to
   users, (not code) so certain privileged operations, such as data
   parsing cannot be performed without an authenticated user, eg
   deserialization.  When data can only be trusted from authenticated
   users.

Removal of AccessController and AccessControlContext have greater 
impact.   AccessController's stack walk is high scaling (I haven't 
observed any contention, I assume it's non blocking and thread 
confined?), it's certainly very performant, it could be replaced 
internally by StackWalker to reduce OpenJDK's maintenance burden, 
although it isn't clear what the performance impact might be, but it 
will no doubt performance improvement is possible.


With SecurityManager gone, no implementation and no policy provider, it 
simply provides the mechanics for an authorization layer without all the 
baggage, allowing both simple and complex implementations.  It's not for 
sandboxing untrusted code. Improvements will allow it to be utilised by 
developers, to prevent consumption of untrusted code or data and to 
limit the privileges of trusted code and users to principles of least 
privilege.


It should also simplifies many tests, as JDK code only need confirm 
Permission checks are made and functionality of the AccessController and 
AccessControlContext methods if these are retained (I would prefer to 
see that, at least for JAAS compatibility).


--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.

Re: Low level hooks in JDK for instrumentation of permission checks.

[Peter Firmstone]

Just a quick question, would it be possible that some JFR hooks might 
also be useable for an authorisation layer?


Regards,

Peter.

On 9/06/2021 11:35 am, Peter Firmstone wrote:


Apologies in advance if this seems like paranoid security.

As you are likely now aware, we have been using SecurityManager a 
little differently than recommended as we adapted it to our requirements.


Sometimes it's not always easy to explain or obvious why something is 
done in a certain way.


It's clear we can use StackWalker to implement AccessController 
functionality.  And it's also clear we can use ThreadLocal or Scope 
Local's to preserve the user Subject across threads.


Going forward we will need low level hooks in the JDK for our 
authentication layer, clearly this is an opportunity to further 
simplify and improve our authentication layer.


Because we use a remote service architecture, with proxy's, the 
proxy's are dynamically granted permission's after Service 
Authentication, these permissions also require the user principal to 
be logged in, we may have a number of services on the stack, for 
example to participate in a transaction.


We have a tool to generate least privilege policy files.

There are two reasons we do this:

 1. Simplicity of administration and auditing of policy files.
 2. Limit the permissions of code, and grant certain permissions to
users to ensure users are authenticated before allowing data parsing.

An example of item two, is our services require users to be logged in 
to ensure that any data provided by the user is a trusted data source 
(we still check the data).   We re-implemented a subset of Java 
Serialization and have a DeSerializationPermission, which is granted 
to Principals of users.


If a user is not logged in, data cannot be de-serialized, because the 
code alone doesn't have permission to do so.


Hopefully modules and packages will have strong encapsulation in 
future so we don't need permission's like java.lang.RuntimePermission 
"accessClassInPackage.*"  No doubt we will need to create our own 
Permission's.


We would like to be able to limit data parsing, like XML or Java 
de-serialization, to logged in users only.


We don't break encapsulation, in future we will only use reflection to 
call public methods and constructors (we are currently in the process 
of doing so).   Our build systems use Maven, our build is modular.


I would also like to request that all JDK modules be given 
ProtectionDomain's  with CodeSource's for modules with 
meaningful URL's jrt:java.* or jrt:jdk.*  following 
SecurityManager deprecation.  Currently some modules have null 
ProtectionDomain's to show they have AllPermission. However we don't 
grant AllPermission to code in practise, we like to grant certain 
Permission's to Principal's, not code, where the Principal is the 
source of data, indicating the user has been authenticated and we only 
grant what's necessary and no more.


Examples of permission's granted to JDK modules in POLP policy files, 
taken from a test harness:


grant codebase "jrt:/jdk.security.jgss"
{
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
    permission java.security.SecurityPermission 
"putProviderProperty.JdkSASL";

};

grant codebase "jrt:/jdk.crypto.mscapi"
{
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";

    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.security.SecurityPermission 
"putProviderProperty.SunMSCAPI";

};

grant codebase "jrt:/jdk.localedata"
{
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.util.resources";

};

grant codebase "jrt:/jdk.security.auth"
{
    permission java.io.FilePermission 
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", 
"read";

    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission 
"modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission 
"modifyPublicCredentials";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";

    permission java.lang.RuntimePermission "getProtectionDomain";
};

Example of POLP grant to code with principal, code alone cannot access 
these, in case you are wondering, we use this to secure the RMI 
Registry using stateless TLSv1.3, it's used by our Service Watchdog, 
or Service Activation framework called Phoenix, it's the sole use we 
have of the Java RMI JRMP protocol, in cases where this isn't used we 
can disa

Re: Low level hooks in JDK for instrumentation of permission checks.

[Peter Firmstone]

Thanks Alan,

You've hit the nail on the head.

In policy implementations, a null CodeSource in PD, is assigned 
AllPermission.   So it would require adding grant statements for these 
modules in the default policy file that ships with the JVM.


I thought it's an opportunity to make ProtectionDomain a little more 
useful if it maps to modules.


Gut feel is it would be relatively low risk, but as you correctly state, 
would require testing.


I'm not able to lodge on Jira, but I thought this would be worthy update.

Regards,

Peter.

On 10/06/2021 4:22 pm, Alan Bateman wrote:

On 10/06/2021 03:49, Peter Firmstone wrote:

Hi Sean,

Sorry I've confused you.

What I should have said is a ProtectionDomain with a null CodeSource.

What I mean to ask is, where ProtectionDomain is created with a null 
CodeSource, in Class::getProtectionDomain() can we have CodeSource's 
that represents system modules instead of null?


A CodeSource with URL's like jrt:/jdk.* or jrt:/java.*  for system 
modules?


This is already the case for system modules that are mapped to the 
platform or application class loaders. I think your question is about 
modules that are mapped to the boot loader and whether they should get 
a unique PD that includes a useful code source rather than using a 
"shared" PD. That would be changing long standing behavior and would 
require careful analysis to see if anything would break.


-Alan

Re: Low level hooks in JDK for instrumentation of permission checks.

[Peter Firmstone]

Hi Sean,

Sorry I've confused you.

What I should have said is a ProtectionDomain with a null CodeSource.

What I mean to ask is, where ProtectionDomain is created with a null 
CodeSource, in Class::getProtectionDomain() can we have CodeSource's 
that represents system modules instead of null?


A CodeSource with URL's like jrt:/jdk.* or jrt:/java.*  for system modules?

Hopefully my comments below will make a little more sense now.

Regards,

Peter.

On 10/06/2021 1:07 am, Sean Mullan wrote:



On 6/8/21 9:35 PM, Peter Firmstone wrote:
I would also like to request that all JDK modules be given 
ProtectionDomain's following SecurityManager deprecation. Currently 
some modules have null ProtectionDomain's to show they have 
AllPermission.  However we don't grant AllPermission to code in 
practise, we like to grant certain Permission's to Principal's, not 
code, where the Principal is the source of data, indicating the user 
has been authenticated and we only grant what's necessary and no more.


As described in JEP 411, there are no plans to deprecate 
ProtectionDomain at this time.


--Sean

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

[Peter Firmstone]

I can re-license some code that decorates Concurrent collections with 
references, so you can do this without blocking.


https://pfirmstone.github.io/JGDMS/jgdms-collections/apidocs/index.html

On 9/06/2021 4:31 am, Alan Bateman wrote:

On Tue, 8 Jun 2021 18:22:55 GMT, Weijun Wang  wrote:


I thought about that but not sure of performance impact. Is the worst problem 
that more than one warnings will be printed for a single caller? It's not 
really harmless.

As for the frame, if the warning message only contain the caller class name and 
its code source, why is it worth using a key of multiple frames? The message 
will look the same.

WeakHashMap access needs synchronization. Whether we need to cache to avoid 
excessive warnings isn't clear. If the SM is enabled once and never 
disabled/re-enabled then caching isn't interesting.  On the other hand if there 
are programs that are enabling/disabling to execute subsets of code then maybe 
it is. Maybe we should just drop this and see if there is any feedback on the 
repeated warning?

Not sure what you meant by "WeakHashMap access synchronization", it's just a 
noun without any other parts. Do you think synchronization is necessary?

For the cache, I'm OK to drop it at the moment.

I think it would be simpler to start out without the caller cache. Sorry the 
sentence got garbled, I was trying to repeat what I said above that WeakHashMap 
is not synchronized so you would need to add synchronization to use it.

-

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


--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Low level hooks in JDK for instrumentation of permission checks.

[Peter Firmstone]

ePermission 
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\mahalo-dl-3.1.1-SNAPSHOT.jar", 
"read";
    permission java.io.FilePermission 
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\mahalo-service-3.1.1-SNAPSHOT.jar", 
"read";
    permission java.io.FilePermission 
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\mahalo.keystore", 
"read";
    permission java.io.FilePermission 
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\outrigger.keystore", 
"read";
    permission java.io.FilePermission 
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", 
"read";
    permission java.io.FilePermission 
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", 
"read";
    permission java.io.FilePermission 
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", 
"read";

    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission net.jini.discovery.DiscoveryPermission 
"QATestDefaultGroup_DESKTOP-R0ORPA2_1623111918992";

};

--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.

Re: JEP 411: Documentation on the new way to establish TLS connections

[Peter Firmstone]

Don't bother replying.

I found that it is actually on the TODO list.

https://bugs.openjdk.java.net/browse/JDK-8266592

I've had enough now anyway, there is no fixing this mess.

Sayonara.


On 4/06/2021 2:22 pm, Peter Firmstone wrote:
Could someone please advise the recommended way now to preserve the 
Subject in Executors to establish a TLS connection?


I am unable to find the documentation.

We use Executors and we preserve the calling Subject across them, to 
use for authentication our TLS endpoints.


This is now deprecated in Java 17, because it uses AccessController 
and AccessControlContext  methods.


I would like to do this in a way that's not deprecated?

Just wondering if anyone has any suggestions?

Ron mentioned on Reddit this morning that there are no new API's being 
developed.


https://bugs.openjdk.java.net/browse/JDK-8267108

Is the assumption that the JDK will be a single user process, so the 
subject just needs to be stored in a Static variable and accessed from 
there instead?


Just wondering what the use case scenario is?

This really sux for us, because we authenticate TLS connections, then 
we run the users with their calling Subjects.


Thank you.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/FilterX509TrustManager.java 
<https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/FilterX509TrustManager.java>
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/SubjectCredentials.java 
<https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/SubjectCredentials.java>


I'm kinda getting the feeling that I'm no longer welcome here.

I recognize that I'm pushing back, and people don't like that, however 
I'm doing so because I am impacted by the recent decision, I can 
assure you I have no personal grudges against anyone.


I'm not looking for assurances that that isn't the case, I just want 
some guidance, I think our whole code base and how we use Java, just 
bit the dust.


--
Regards,
  
Peter.

JEP 411: Documentation on the new way to establish TLS connections

[Peter Firmstone]

Could someone please advise the recommended way now to preserve the 
Subject in Executors to establish a TLS connection?


I am unable to find the documentation.

We use Executors and we preserve the calling Subject across them, to use 
for authentication our TLS endpoints.


This is now deprecated in Java 17, because it uses AccessController and 
AccessControlContext  methods.


I would like to do this in a way that's not deprecated?

Just wondering if anyone has any suggestions?

Ron mentioned on Reddit this morning that there are no new API's being 
developed.


https://bugs.openjdk.java.net/browse/JDK-8267108

Is the assumption that the JDK will be a single user process, so the 
subject just needs to be stored in a Static variable and accessed from 
there instead?


Just wondering what the use case scenario is?

This really sux for us, because we authenticate TLS connections, then we 
run the users with their calling Subjects.


Thank you.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/FilterX509TrustManager.java 

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/SubjectCredentials.java 



I'm kinda getting the feeling that I'm no longer welcome here.

I recognize that I'm pushing back, and people don't like that, however 
I'm doing so because I am impacted by the recent decision, I can assure 
you I have no personal grudges against anyone.


I'm not looking for assurances that that isn't the case, I just want 
some guidance, I think our whole code base and how we use Java, just bit 
the dust.


--
Regards,
 
Peter.

Re: Authorization Layer post JEP 411

[Peter Firmstone]

Sean,

Also moving forward we currently preserve AccessControlContext across 
threads, and we do this to establish TLS connections for call backs.


Will there be a new way to preserve the calling Subject across threads, 
so we can perform callbacks over TLS?


Regards,

--
Regards,
 
Peter Firmstone


On 4/06/2021 7:39 am, Peter Firmstone wrote:

Hi Sean,

Developers are still going to need single points of control, where we 
can attach our agents to Java's API's.   We can't be playing a game of 
whack a mole trying to lock down the JDK.


It's fair enough that OpenJDK no longer wishes to maintain 
SecurityManager, however there are those of us who have to implement 
authorization layers and access controls and we don't have the luxury 
of choice.


So we've established that we need to use Agents and StackWalker now to 
implement our authorization layer.


It will be some years before we are able to keep up to date with Java 
releases again, but now we need to focus on how to achieve that.


Regarding your questions, the performance problems, were related to 
Java's FilePolicy implementation, I solved those issues by replacing 
it, but you're already aware of that, I was highlighting the struggle 
that developers have with Java security, but also that JAAS is a 
common foundation for user authorisation, so I hope that it will be 
improved, rather than removed.  I of course also use JAAS to establish 
TLS connections.


If there's anything else OpenJDK is thinking about, thinking about 
removing, then we need to know, so we don't use them in our new 
authorization layer.

Re: Authorization Layer post JEP 411

[Peter Firmstone]

Hi Sean,

Developers are still going to need single points of control, where we 
can attach our agents to Java's API's.   We can't be playing a game of 
whack a mole trying to lock down the JDK.


It's fair enough that OpenJDK no longer wishes to maintain 
SecurityManager, however there are those of us who have to implement 
authorization layers and access controls and we don't have the luxury of 
choice.


So we've established that we need to use Agents and StackWalker now to 
implement our authorization layer.


It will be some years before we are able to keep up to date with Java 
releases again, but now we need to focus on how to achieve that.


Regarding your questions, the performance problems, were related to 
Java's FilePolicy implementation, I solved those issues by replacing it, 
but you're already aware of that, I was highlighting the struggle that 
developers have with Java security, but also that JAAS is a common 
foundation for user authorisation, so I hope that it will be improved, 
rather than removed.  I of course also use JAAS to establish TLS 
connections.


If there's anything else OpenJDK is thinking about, thinking about 
removing, then we need to know, so we don't use them in our new 
authorization layer.


--
Regards,
 
Peter Firmstone


On 4/06/2021 1:02 am, Sean Mullan wrote:



On 6/2/21 7:41 PM, Peter Firmstone wrote:
AccessController and AccessControlContext allow backward compatiblity 
for JAAS.   JAAS whether we like it or not, is the default 
authorisation layer framework.


http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ 





I'm not sure why you referenced this blog which is actually advocating 
that JAAS has *less* dependency on Security Manager APIs such as 
AccessControlContext, whereas you seem to be advocating the opposite.


In any case, I believe the first two issues in this blog will largely 
be addressed by the deprecation of the Security Manager and the JAAS 
related RFEs that we have filed as follow-on work to JEP 411 to remove 
the dependencies on the SM APIs:


https://bugs.openjdk.java.net/browse/JDK-8266592
https://bugs.openjdk.java.net/browse/JDK-8267108

As for the 3rd issue in the blog, it is not related to the Security 
Manager, but I would need more time to understand the issues that were 
described.


Also the blog was written by David Lloyd who has been participating in 
these discussions, so he may want to say more about it.


--Sean

Re: [External] : Authorization Layer post JEP 411

[Peter Firmstone]

Yes, I think so too.  However I will encourage developers to continue to 
take advantage of SM for improved security now, there's no need to rush 
to abandon it.


Maybe in future there will be better alternatives, but it's the best 
option for those who are security focused now.


With time no doubt hardening that will occur to the Java platform as 
OpenJDK responds to vulnerabilities, it will become the most secure 
option again, but I think that's a number of years away and I'd rather 
be conservative than get burned.


If SM deprecation doesn't impact your use case, then yes I would 
encourage you to upgrade, because that's the sensible thing to do.


I'll still test on later versions, but I won't be removing our 
authorization system until I'm satisfied there are sufficiently hardened 
alternative technologies available.


Thank you,

Peter.

On 3/06/2021 7:58 pm, Ron Pressler wrote:

It is certainly time to accept that JEP 411 has been accepted, and so that those
who use Security Manager will need to do some work to change their software.

The purpose of this and upcoming discussions is to find reasonable approaches
that might relieve some portion of the burden on those who use SM today while
not placing an undue (indirect) burden on those who do not.

— Ron


On 3 Jun 2021, at 10:43, Peter Firmstone  wrote:

Ok, thanks Ron,

I think we are confirming that Java, post version 17, will not meet the 
security needs our software.  It's time I accepted that and moved on.

Thanks for your time.

Have you seen my latest article on foojay?   Feel free to comment and let me 
know what you think.

https://urldefense.com/v3/__https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje9M4Wtv3A$
Cheers,

Peter.


On 3/06/2021 7:33 pm, Ron Pressler wrote:

On 3 Jun 2021, at 00:41, Peter Firmstone  wrote:


StackWalker doesn't work with compiled code, only bytecode.

If you’re referring to GraalVM’s Native Image, I don’t know about that problem 
and
there does seem to be a relevant patch 
(https://urldefense.com/v3/__https://github.com/oracle/graal/pull/734__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-DV8ldZw$
 ), but
Native Image is a separate project from OpenJDK.


AccessController and AccessControlContext allow backward compatiblity for JAAS. 
  JAAS whether we like it or not, is the default authorisation layer framework.

https://urldefense.com/v3/__http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-R7C-0Hg$

I don’t know how much a seven-year-old article, that predates Java 8 supports 
the use
of the present tense, but in any event, the JEP says that JAAS will be 
preserved.


With SecurityManager gone, people will no longer assume it has sole responsible 
for Security

People don’t assume that now, as secure software doesn’t employ it even today. 
People do,
however, assume that the mechanism, if used, is robust enough to be used for 
security
purposes.


OpenJDK devs won't carry a significant burden for it's maintenance.

While the number of places where the JDK *implements* some “protected 
operation”, like
opening a file or writing to a socket, is somewhat bounded — and so keeping 
some hooks
in those places *might* be reasonable — the number of places that *use* those 
operations
is not. Maintaining doPrivileged in that unbounded set of places is not an 
insignificant
burden.



Any security issues will be the responsibility of third party implementations, 
like mine.
The JDK won't provide an implementation, just the framework.

But the correct use of doPrivileged, if you’re proposing that it’s kept, must 
still be
tested against *some* implementation, and OpenJDK would still need to fix bugs 
related
to it.


Those of us using the Principle of Least Privilege can continue to do so

Perhaps you believe that the only software in the world that applies Least 
Privilege is
Java software that employs the Security Manager, but that is not how most 
people, including
the person who had framed it two decades prior to the invention of the Security 
Manager,
understand the principle.

The original statement of the principle was: "Every program and every 
privileged user of
the system should operate using the least amount of privilege necessary to 
complete the
job.” 
(https://urldefense.com/v3/__https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-xd8krsA$
 )

You are talking about applying the principle at a granularity of code units 
that are
smaller than a program. It’s fine to believe that is worthwhile, but the 
principle
certainly doesn’t require that every effort be expended to afford least 
privilege at
any granularity.


and we can participate in OpenJDK to maintain Permission checks where we

Re: [External] : Authorization Layer post JEP 411

[Peter Firmstone]

Ok, thanks Ron,

I think we are confirming that Java, post version 17, will not meet the 
security needs our software.  It's time I accepted that and moved on.


Thanks for your time.

Have you seen my latest article on foojay?   Feel free to comment and 
let me know what you think.


https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/

Cheers,

Peter.


On 3/06/2021 7:33 pm, Ron Pressler wrote:



On 3 Jun 2021, at 00:41, Peter Firmstone  wrote:


StackWalker doesn't work with compiled code, only bytecode.

If you’re referring to GraalVM’s Native Image, I don’t know about that problem 
and
there does seem to be a relevant patch 
(https://github.com/oracle/graal/pull/734), but
Native Image is a separate project from OpenJDK.


AccessController and AccessControlContext allow backward compatiblity for JAAS. 
  JAAS whether we like it or not, is the default authorisation layer framework.

http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/

I don’t know how much a seven-year-old article, that predates Java 8 supports 
the use
of the present tense, but in any event, the JEP says that JAAS will be 
preserved.


With SecurityManager gone, people will no longer assume it has sole responsible 
for Security

People don’t assume that now, as secure software doesn’t employ it even today. 
People do,
however, assume that the mechanism, if used, is robust enough to be used for 
security
purposes.


OpenJDK devs won't carry a significant burden for it's maintenance.

While the number of places where the JDK *implements* some “protected 
operation”, like
opening a file or writing to a socket, is somewhat bounded — and so keeping 
some hooks
in those places *might* be reasonable — the number of places that *use* those 
operations
is not. Maintaining doPrivileged in that unbounded set of places is not an 
insignificant
burden.



Any security issues will be the responsibility of third party implementations, 
like mine.
The JDK won't provide an implementation, just the framework.

But the correct use of doPrivileged, if you’re proposing that it’s kept, must 
still be
tested against *some* implementation, and OpenJDK would still need to fix bugs 
related
to it.


Those of us using the Principle of Least Privilege can continue to do so

Perhaps you believe that the only software in the world that applies Least 
Privilege is
Java software that employs the Security Manager, but that is not how most 
people, including
the person who had framed it two decades prior to the invention of the Security 
Manager,
understand the principle.

The original statement of the principle was: "Every program and every 
privileged user of
the system should operate using the least amount of privilege necessary to 
complete the
job.” (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939)

You are talking about applying the principle at a granularity of code units 
that are
smaller than a program. It’s fine to believe that is worthwhile, but the 
principle
certainly doesn’t require that every effort be expended to afford least 
privilege at
any granularity.


and we can participate in OpenJDK to maintain Permission checks where we need 
them and preserve context where appropriate.

I think you’re underestimating the magnitude of this work, which potentially 
interacts with
each and every change in the JDK (and in practice interacts with many of them, 
and today it’s
done by those who are responsible for the relevant change), which you’ll need 
to monitor,
not to mention that OpenJDK Reviewers, a role granted only to the most 
experienced contributors,
would still have to review that work.

However, if you think that is an amount of work you could manage, perhaps it 
could be done
outside the JDK using Java Agents.


JAAS will continue to remain functional

The JEP already intends to keep JAAS functional, as far as I can tell.

— Ron

Re: Authorization Layer post JEP 411

[Peter Firmstone]

Apologies, I meant when compiled to native code, when you ship native 
binaries.


Having said that, if it's necessary to use StackWalker behind 
AccessController.doPrivileged going forward then lets do so, and maybe 
the native binary is a later feature.


Hopefully my proposal is getting some consideration.

--
Regards,
 
Peter.


On 3/06/2021 5:18 pm, Alan Bateman wrote:



On 03/06/2021 01:04, Chapman Flack wrote:

On 06/02/21 19:41, Peter Firmstone wrote:
We need the power of AccessController's stack walk, StackWalker 
doesn't work

with compiled code, only bytecode.

Is this correct? I have not tried it, but the apidocs had led me to
understand it did not distinguish much between JITed and interpreted 
code.

Even getByteCodeIndex does not mention any limitation when the frame is
JITed Java code (though it does say it will return a negative number in
the distinct case of an actual native method).

There should be no issue here. I suspect Peter meant that the stack 
walker is about walking Java frames, it's transparent whether there 
are interpreter frames, compiled frame, or a mix on the stack.


-Alan