subject:"JEP 411, removal of finalizers, a path forward."


Maybe we need some criteria, that defines what's not easily instrumented?

On 4/08/2021 10:19 am, Peter Firmstone wrote:


Excellent, Ron, that's exactly what I'm after.

I need to be able to implement an authorization layer on top of the 
JDK, but reach down into the JDK to use authorization to control access.


Can we find out how many such checks that OpenJDK is prepared to 
support, then we will pick the most important?


Don't worry about ClassLoader, I can instrument that (thank you Erik), 
and maybe I can instrument Properties, and System.exit. So basically 
things we can't easily instrument with agents, that everybody is most 
likely to want.


  * Network access
  * File System access
  * User Credentials

Maybe we should have a mailing list dedicated to this where we can 
discuss and potentially collaborate?


Regards,

Peter.

On 3/08/2021 10:15 pm, Ron Pressler wrote:

On 3 Aug 2021, at 12:50, Peter Firmstone  wrote:

Can you think of any workable alternative compromises?

If you mean a compromise between no access checks in the JDK and all access 
checks in the JDK, then yes,
which is possibly some callbacks for a small subset of operations that perform 
access checks today,
say, System.exit and opening a file or socket. I am not saying this is what 
should be done, but that the
effort involved is such that I can conceivably see those whose responsibility 
this would be agreeing to
consider it, as the value in such a mechanism might end up being worthy of that 
amount of effort. But I’m
guessing that the more such hooks are requested, the less likely it is that the 
cost remains acceptable.

— Ron


--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

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


Excellent, Ron, that's exactly what I'm after.

I need to be able to implement an authorization layer on top of the JDK, 
but reach down into the JDK to use authorization to control access.


Can we find out how many such checks that OpenJDK is prepared to 
support, then we will pick the most important?


Don't worry about ClassLoader, I can instrument that (thank you Erik), 
and maybe I can instrument Properties, and System.exit. So basically 
things we can't easily instrument with agents, that everybody is most 
likely to want.


 * Network access
 * File System access
 * User Credentials

Maybe we should have a mailing list dedicated to this where we can 
discuss and potentially collaborate?


Regards,

Peter.

On 3/08/2021 10:15 pm, Ron Pressler wrote:



On 3 Aug 2021, at 12:50, Peter Firmstone  wrote:

Can you think of any workable alternative compromises?

If you mean a compromise between no access checks in the JDK and all access 
checks in the JDK, then yes,
which is possibly some callbacks for a small subset of operations that perform 
access checks today,
say, System.exit and opening a file or socket. I am not saying this is what 
should be done, but that the
effort involved is such that I can conceivably see those whose responsibility 
this would be agreeing to
consider it, as the value in such a mechanism might end up being worthy of that 
amount of effort. But I’m
guessing that the more such hooks are requested, the less likely it is that the 
cost remains acceptable.

— Ron

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


On 4/08/2021 2:40 am, Sean Mullan wrote:




On 8/2/21 8:28 PM, Peter Firmstone wrote:

In JGDMS without SM, at least the following must be addressed to
maintain security:

  1. TLS and Kerberos connections cannot be established.  (My 
software is
 littered with doPrivileged calls that preserve the Subject, we 
don't

 have anon TLS connections, we require client certificates).


As mentioned several times, this use case will be preserved and is 
already covered in JEP 411: 
https://openjdk.java.net/jeps/411#subject-doas


Yes, that's true, a secondary consideration is the amount of work that 
will be required to support different versions of Java, no doubt 
reflection will be helpful, to check for the existence of the new 
methods.   Last time I checked, I have around 1,000 locations in the 
code that will require changes.   My motivation for mentioning it was to 
highlight the benefit of reusing existing methods, which currently 
provide this functionality.





  2. All remote connections are authorized to load classes.


Not sure why you can't do something with a custom ClassLoader that 
only loads classes for authorized users.


Interesting, what do you have in mind?

We currently do have a hierarchy of custom ClassLoaders, however its 
concern is class resolution at client endpoints (Warning this isn't 
simple and may be confusing if you're not familiar with Jini and I may 
not be able to explain it sufficiently for it to be simply understood).


We have solved some extremely difficult software design problems that 
Sun Microsystems left unresolved with Jini.


https://dl.acm.org/doi/epdf/10./1698139

Our software architecture is designed for separation of concerns.  
Grafting authorization onto ClassLoader's doesn't sound like a good 
design decision, however I'm listening.


Our current ClassLoader inheritance hierarchy:

SecureClassLoader -> URLClassLoader -> RFC3986URLClassLoader -> 
PreferredClassLoader


The reason I highlight SecureClassLoader is, we override 
SecureClassLoader methods to replace CodeSource, with a CodeSource that 
uses RFC3986 and RFC5952 normalization for identity in 
SecureClassLoader, to avoid DNS calls and to normalize IPv6 addresses 
where DNS isn't used and endpoints contact each other directly and their 
identity needs to be defined by their normalized address.


However, PreferredClassLoader, modifies class resolution, allowing the 
authenticated service to resolve classes that it prefers, from it's own 
CodeSource, before they are loaded from the parent ClassLoader, that it 
lists as preferred, allowing the service to have a weak form of 
Isolation (we didn't design this, inherited from Sun).


In our JERI (Jini Extensible Remote Invocation) Endpoints, ClassLoader's 
are assigned at both Client and Server Endpoint's, for class resolution 
(we designed this), and at the client endpoint, each ClassLoader is 
unique to the identity of the Service, the authenticated Subject of the 
Service, is part of the Service identity.  Only the Service can 
deserialize (not Java serialization) into this ClassLoader, but only 
after authenticating.


Unlike Java RMI, we don't annotate codebases in the stream (a mistake 
that duplicates the ClassLoader class resolution mechanism), instead we 
assign ClassLoaders for class resolution at both endpoints when the 
streams are created, the ClassLoader is provisioned with the correct 
codebase for the service, after authentication.


A user is assigned GrantPermission( Insert Java permission here) in 
policy files, users can dynamically grant permissions to a Service, 
after it has authenticated, the service, advises the client of 
Permissions it needs, the permissions granted are the intersection of 
the sets of what the client is willing and authorized to grant, and the 
permissions requested by the Service.


This might highlight why the simplest option at this time is to 
re-implement an authorization layer.


The resulting capability and power of these features are not widely 
understood or known.   Think of a service, that can be advertised on any 
IPv6 network, anywhere in the world, and be discovered by a user on an 
IPv6 anywhere else in the world, without an intermediary.  Over secure 
sockets.  Provided the user and the service have common trust 
certificates, they could be from the same company, or part of a club or 
organization.


For example multiple parties can participate in a transaction globally.




  3. All remote connections are authorized to perform deserialization.


Depending on serialization long-term seems somewhat dubious.


Agreed, in many of my previous emails I've added brackets after 
serialization that state (not Java serialization), perhaps I should just 
start calling it not Java serialization, this was written prior to the 
introduction of serialization filters, to address the shortcomings of 
Java Serialization, it's a subset of Java serialization re-implemented 
to use constructors and

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

> On 3 Aug 2021, at 12:50, Peter Firmstone  wrote:
> 
> Can you think of any workable alternative compromises?

If you mean a compromise between no access checks in the JDK and all access 
checks in the JDK, then yes,
which is possibly some callbacks for a small subset of operations that perform 
access checks today, 
say, System.exit and opening a file or socket. I am not saying this is what 
should be done, but that the 
effort involved is such that I can conceivably see those whose responsibility 
this would be agreeing to
consider it, as the value in such a mechanism might end up being worthy of that 
amount of effort. But I’m
guessing that the more such hooks are requested, the less likely it is that the 
cost remains acceptable.

— Ron

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

> On 3 Aug 2021, at 06:48, Peter Firmstone  wrote:
> 
> 
> We can still use these without an SM, Policy or Permissions for authorization 
> decisions, as mentioned previously I'd replace the inherited thread context 
> with an unprivileged context, and also allow the stack walk to be disabled 
> for people only using Subject.
> 

I think what you mean is that you can envision using the same API points for a 
different, but reasonably similar 
role to the one they have. But that would mean changing the behaviour of 
existing classes, possibly making some
final classes non-final, in non-trivial ways. 

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

The plan is to degrade these into no-ops until such time as most of those 
usages disappear, not to imbue
those lines of code with new meaning. The actual removal of the API elements 
might be a long way off,
but, becoming no-ops before then, the JDK and libraries will be free to remove 
those usages.

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

> On 3 Aug 2021, at 09:39, Peter Firmstone  wrote:
> 
> 
> 
> Can you elaborate?   A Runnable, similar to registering a shutdown hook?
> 

Maybe, but there have been no specifics beyond saying that something like that, 
and 
which requires that level of effort, might, after the dust settles and no one 
is rushing
to decisions, possibly be something that we could contemplate thinking about 
considering 
as possibly not being obviously completely unreasonable, and might, perhaps, be 
worthy
of another look.

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

What you are proposing is:

1. Add an SPI for deep permission checks in the JDK.
2. Do so by changing the behaviour of existing classes in a non-trivial way.
3. Keep access checks in the JDK.

I do not speak for those who work on the security mechanisms, but I believe 
that none one of these,
even in isolation, would be reasonable.

For one, even without the principle against changing the behaviour of existing 
classes in drastic
and non-trivial ways, without the use of doPrivileged in the JDK, 
AccessController would make
a bad API.

For another, the cost of SM isn’t in the lines of code that make up the 
AccessController implementation
but in the fact that the JDK does access checks and privileged operations in 
the first place, as those 
impose a tax on everything, and also take resources away from what we believe 
is more robust and effective 
security.

The starting point isn’t removing the policy file implementation, but removing 
all access checks
and privileged operations from the JDK, and everything else follows from there 
(it will take a long
time until API elements are actually removed, anyway). Even if someone might 
choose to contemplate adding 
callbacks to one or two I/O operations, it is not the intent for the JDK to 
participate in a general access 
checking mechanism deep in its guts in addition to strong encapsulation; quite 
the opposite.


— Ron


> On 3 Aug 2021, at 10:44, Peter Firmstone  wrote:
> 
> Thanks Ron, reply inline.
> 
> On 3/08/2021 6:48 pm, Ron Pressler wrote:
>> 
>>> On 3 Aug 2021, at 06:48, Peter Firmstone 
>>>  wrote:
>>> 
>>> 
>>> We can still use these without an SM, Policy or Permissions for 
>>> authorization decisions, as mentioned previously I'd replace the inherited 
>>> thread context with an unprivileged context, and also allow the stack walk 
>>> to be disabled for people only using Subject.
>>> 
>>> 
>> I think what you mean is that you can envision using the same API points for 
>> a different, but reasonably similar 
>> role to the one they have. But that would mean changing the behaviour of 
>> existing classes, possibly making some
>> final classes non-final, in non-trivial ways. 
>> 
> I'd limit changes to:
> 
>   • Make the stack walk optional (via command line argument to disable 
> it).
>   • Remove Thread's inherited context, replace it with an unprivileged 
> context.
> This would allow us to use the API for virtual threads, eg to obtain Subject 
> credentials to authenticate TLS connections.
> 
> It also means that for someone implementing guard checks, that these only 
> need check the thread stack back to the last doPrivileged call, or the start 
> of the thread, in the latter case it will have no privileges.  It fixes the 
> viral permission check problem, usually doPrivileged calls are short and 
> sweet.
> 
> It may require the addition of doPrivileged calls where they're currently 
> missing (and should have been used), where they've been responsible for viral 
> permission checks.
> 
>> 
>>> Just performed a search for java.security.AccessController on GitHub, got 
>>> 1,398,418 results for Java:
>>> 
>>> 
>> The plan is to degrade these into no-ops until such time as most of those 
>> usages disappear, not to imbue
>> those lines of code with new meaning. The actual removal of the API elements 
>> might be a long way off,
>> but, becoming no-ops before then, the JDK and libraries will be free to 
>> remove those usages.
>> 
> No new meanings, the same as they have now is sufficient, just we leave the 
> granularity of the checks to the developers of guards and provide a means by 
> which guards can be registered for common check points that developers 
> request (perhaps via a poll), rather than all existing permission check 
> points.  Keeping in mind that we are not trying to isolate code, but perform 
> authorization access checks, as well as provide credentials for 
> authentication.
> 
> For example, if someone is only concerned with stopping the JVM from exiting, 
> then they only implement a guard for that particular hook, the actual code 
> that needs to call System::exit, then calls a doPrivileged method before 
> doing so.  The guard need only check the domain on the stack is the one it 
> expects, which could be based on Principal, CodeSource, Module or ClassLoader 
> etc, they may also chose to implement something more complex.
> 
> Someone else may only be concerned with network connections, so they only 
> implement and register a guard for that.
> 
> So basically we don't dictate how to implement guards or policy, we just 
> leave enough in place, to ensure that a minimalist authorization access 
> control api is common among all implementations on all Java versions.
> 
> It is suitable, for Subject's only or code and Subject's.
> 
> The doPrivileged call simply indicates the code is requesting to do something 
> that might be privileged, or needs to provide credentials for authentication, 
> as it does now, but

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

> On 3 Aug 2021, at 02:30, Peter Firmstone  wrote:
> 
> 
> I am still hopeful that OpenJDK might create some hooks for us and keep the 
> AccessController, AccessControlContext and Subject.doAs methods to make 
> supporting all Java versions easier.

When I mentioned “hooks” I was referring to something along the lines of a 
callback when a file is
accessed.

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

When you transform a class, you basically replace its content with new content, 
so the short answer is 
that what happens to line numbers is whatever you want. If you’re using ASM for 
your transformation and 
ignore line numbers, which ASM represents as a kind of no-op instructions, then 
what would usually happen 
is that if original instruction X is mapped to line N and when transforming the 
stream you replace X with 
YXZ, then all of YXZ will remain mapped to line N.

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

Our path to making Java more secure is, indeed, similar to what you’re 
proposing.

The general direction is that the application, rather than the libraries, will 
have the final say on security-sensitive capabilities.
Just as strong encapsulation is now on by default, other things, such as native 
code, some dynamic Agent capabilities, and 
perhaps others, will likely require explicit permission by the application on 
the command line. I don’t know the details about
management, but I believe that remote management requires explicit permission 
already.

I am not aware, however, of plans to restrict class loading. The idea is that 
code is trusted to do what it says it does, and 
what’s restricted is the ability to manipulate it (without permission) to do 
something else through transformation or 
circumvention of its declared API.

The default security policy today is already more restrictive than it was a 
couple of versions ago, and we expect it to become 
even more restrictive.

— Ron

> On 2 Aug 2021, at 11:33, Peter Firmstone  wrote:
> 
> Hello Andrew,
> 
> I think you may be misinterpreting my comment, let me clarify:
> 
> I'm assuming that during the process of removal of security manager, any 
> external ports or process hooks that we can only turn off now by not granting 
> a permission will be replaced by a command line property or something 
> similar?  Eg, Agents, Management, etc. If this is the case, it would be nice 
> if they were set to off by default, such that they needed to be enabled from 
> the command line.  It's a suggestion.   So configuration is secure by 
> default.  Eg, similar to how OpenBSD is configured secure by default, is that 
> something RedHat does?   I used RedHat back in the 90's, it was my first 
> Linux distro, on sparc. :)
> 
> For example, the permissions granted in this policy file:
> 
> https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new__;!!ACWV5N9M2RV99hQ!cVJkwzysH02ZFZWT3rnO_o5viWUCBTm9nnM50QaJ5G9hsg9B3p2naDVYknIrqSNURQ$
>  
> Ensure that anything that isn't specifically granted, is switched off, eg 
> agents, management, etc.
> 
> This file is generated by a policy writing tool, the comments in the policy 
> file, indicate the tests that were run to generate the policy.  It's 
> important to note that we aren't using sandboxing, or isolation, we are 
> simply running with privileges we don't require switched off.   All network 
> entry points to the JVM require authentication and classes loaded, or data 
> parsed requires authentication first.
> 
> In my software without SM, authentication isn't required, and there are no 
> defenses against parsing un-trusted data or downloading and loading malicious 
> classes.  Although you've made it clear, you think this is a /special case/ 
> and /special loss/ you needn't concern yourself with and that's fine, you've 
> made your point.
> 
> In future it will not be possible to switch these features off using policy 
> files, so I imagine that OpenJDK must be considering alternative methods to 
> switch off features that may be security sensitive?
> 
> We already know de-serialization can be switched off from the command line 
> using: -Djdk.serialFilter=!*,
> 
> However if you switch off java de-serialization, you best be sure to 
> initialize the serialization framework when starting your JVM, as SM won't be 
> there to stop it being turned back on, if it's not used, it's not 
> initialized, then the property can be changed and is potentially a link in a 
> gadget chain attack where serialization can be re-enabled. :)  Just saying.
> 
> Not sure what canard you're referring to, is the JDK config secure by 
> default?  If so, then it won't be possible for a malicious java attachment in 
> an email (or an image file) to be run inadvertently and use the attach API to 
> steal secrets.  Although it's processor could be subject to speculative 
> execution attacks.
> 
> A good reason to use OpenBSD (or Solaris perhaps) on Sparc for secure 
> systems?   I know RedHat is into supporting military application in a big 
> way, but I'm surprised if they're not concerned about speculative execution 
> vulnerabilities.
> 
> Speculative execution attacks will eventually be addressed in processor 
> architectures, they are trying, we shouldn't assume that we don't need to 
> program defensively because the underlying architecture has speculative 
> execution bugs.  If we do that, then were do we stop?
> 
> Anyway, if possible I would like to get back to discussing how to instrument 
> the Java API using Agents, and whether we can coordinate removal of 
> finalizers with SM removal.
> 
> Of course if you'd like to keep SM and cancel JEP 411, as Uwe suggested, I'd 
> support that.  I'm also grateful that Uwe spoke up, and I hope others do as 
> well, so this topic receives further productive discussion.  It would be nice 
> to sort the use cases prior to SM

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

Hi.

JEP 411 says that there is a feature whose value in fulfilling its purpose no
longer justifies its high cost, and so it should be removed. What you’re saying
is, that’s true, but you should keep it, anyway. Why? Because it can be put to
some other, more modest, accidental uses. 

Now, the "disaster" of removing any feature is directly felt by those who use
it, but the "disaster" of *not* removing it is less visible, even though it may
be the bigger disaster, as we believe is the case here. Sure, we must consider
those applications that use it and how they use it, but we must also consider
all those that do not. By not acknowledging those who lose from keeping that
mechanism, you're not appreciating the problem that the JEP tries to address.
For example, you say you care about non-security uses of SM, but maintaining it
comes at the cost of other security measures, and we believe that removing it
would improve Java's security overall.

While some of the features you say you want could well be addressed by cheaper
mechanisms that could reasonably be added, it's possible that some cannot
(or not fully). Thankfully, the JDK is flexible and hackable enough — through
things like Java Agents — that the cost of some capabilities could be borne by
those who need them.

It's perfectly reasonable to explain what functionality would be helpful to you.
It is not reasonable to demand keeping some functionality regardless of its
cost. The reality is that to adapt to changing circumstances, the JDK must both
add new capabilities as well as drop old ones, or its complexity, and, with it,
its maintenance cost would grow without bound. Of course, any help in finding
the right balance of cost and benefit in consideration of the needs of
the *entire* ecosystem would be appreciated.

P.S.

Loom has nothing to do with JEP 411. I might have mentioned it when pointing out
that virtually all relevant Java features developed in the past decade -- like
parallel streams, CompletableFuture, and Loom -- have chosen not to integrate
with SM.

— Ron

> On 1 Aug 2021, at 15:28, Uwe Schindler  wrote:
> 
> Hi Andrew,
> 
>>> I'm working on the assumption that OpenJDK will close any external holes
>>> currently defended by permission checks.  It would be good if the JDK
>>> was secure by default, with properties required to be set for allowing
>>> such things as agents, management, parsing xml and serialization.
>> 
>> You need to stop repeating this canard. There is no absolute need for
>> OpenJDK to retain a security mechanism to deal with problems that for
>> almost every use case are better solved by using non-OpenJDK
>> alternatives (such as OS security measures). Indeed, it's the other way
>> round: there is an imperative for the project to spend precious
>> resources on alternative capabilities (not necessarily security related).
> 
> Sorry, as another open source project affected by the stupid JEP 411 desaster 
> I would like to fully confirm to EVERYTHING that Peter said. It is not a 
> canard, it is the reality and I am really disappointed what happened.
> 
> What I figured out: You intend to remove SecurityManager because it does not 
> fit your latest ideas how Java threads should behave. I know the main problem 
> is not "SecurityManager is too complex / too slow / wrongly used /..." -- the 
> main problem of some OpenJDK people around the Loom project is that it won't 
> work correctly with those new type of threads. You are now always arguing 
> against use cases of SecurityManager for the purpose of secuirty because you 
> just want to hide that the new "light" threads (aka fibers) in project Loom 
> are incompatible to the stack-based access control provided by 
> AccessController and SecurityManager. So the only canard is Project Loom - 
> sorry!
> 
> So I will do the same: repeat the same story like Peter's over an over. Two 
> large projects affected by your changes are Apache Solr and Elasticsearch. 
> Both use security manager not only for security purposes, but also to control 
> access to resources and classloading! Speed is also no issue if you use 
> security manager correctly. In Apache Lucene/Solr/Elasticsearch there is NO 
> slowdown visible as the hooks into security manager are only called for 
> uncritical places (like opening a file before mmapping it, open a listening 
> socket, loading a class...).
> 
> The problem is: you deprecate for removal without offering any API to replace 
> the main pain points:
> - preventing exit of JDK
> - an API to control class loading and prevent code from calling 
> Method/Field/Constructor#setAccessible(true) for specific cases (e.g., you 
> want a scripting language like Groovy to not allow caling 
> sun.misc.Unsafe,...). Those things can never be done with code outside of the 
> JVM!
> - Allow to hook into the I/O system. Unfortunately the java.nio FileSystem 
> API is not enough: it does not cover java.io.File (why is this the case?) nor 
> does the FileSystem API

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

2021-08-03 Thread Sean Mullan





On 8/2/21 8:28 PM, Peter Firmstone wrote:

In JGDMS without SM, at least the following must be addressed to
maintain security:

  1. TLS and Kerberos connections cannot be established.  (My software is
 littered with doPrivileged calls that preserve the Subject, we don't
 have anon TLS connections, we require client certificates).


As mentioned several times, this use case will be preserved and is 
already covered in JEP 411: https://openjdk.java.net/jeps/411#subject-doas



  2. All remote connections are authorized to load classes.


Not sure why you can't do something with a custom ClassLoader that only 
loads classes for authorized users.



  3. All remote connections are authorized to perform deserialization.


Depending on serialization long-term seems somewhat dubious.


Having established that OpenJDK is not yet willing to compromise, I have
been attempting to create an authorization layer using Agents, so that I
can restore perimeter security following the removal of SM and support
future versions of Java.   It is my hope that either I will be
successful in recreating an authorization layer, or that enough people
come forward and OpenJDK decides there are enough affected developers to
find a compromise that either makes migration practical, or less expensive.


You may have some interesting ideas, but in my opinion you have not 
presented them in a clear and easily digestible manner, and your long 
emails are time consuming to read, repetitive and often diverge into 
rants. (Keep in mind there are many people on the jdk-dev alias, and a 
lot of them may not care about this topic). It is to the point where I 
only skim your emails quickly. I would take the time to write up your 
ideas in an external place. It may not go anywhere, but at least you 
would have a single place where your proposal, experiments, etc are 
documented.


--Sean

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


Can you think of any workable alternative compromises?

On 3/08/2021 9:21 pm, Ron Pressler wrote:

What you are proposing is:

1. Add an SPI for deep permission checks in the JDK.
2. Do so by changing the behaviour of existing classes in a non-trivial way.
3. Keep access checks in the JDK.

I do not speak for those who work on the security mechanisms, but I believe 
that none one of these,
even in isolation, would be reasonable.

For one, even without the principle against changing the behaviour of existing 
classes in drastic
and non-trivial ways, without the use of doPrivileged in the JDK, 
AccessController would make
a bad API.
That's true, it would better if those doPrivileged calls to remain. An 
alternative I thought about if they were removed, was to treat a thread 
as privileged if all domains on the thread stack were resolvable from 
the bootstrap ClassLoader.


For another, the cost of SM isn’t in the lines of code that make up the 
AccessController implementation
but in the fact that the JDK does access checks and privileged operations in 
the first place, as those
impose a tax on everything, and also take resources away from what we believe 
is more robust and effective
security.


Yes, I realise this, however I'm not looking to replace all permission 
checks, just the most common.  Perhaps then a static method added to a 
class, without implementation would be better, in cases where it's not 
practical to instrument the JVM.  Such that it does nothing by default 
and would be optimised away by hotspot.


eg:

static instrumentGuard(String [] args) throws SecurityException{}

Thanks,

Peter.



The starting point isn’t removing the policy file implementation, but removing 
all access checks
and privileged operations from the JDK, and everything else follows from there 
(it will take a long
time until API elements are actually removed, anyway). Even if someone might 
choose to contemplate adding
callbacks to one or two I/O operations, it is not the intent for the JDK to 
participate in a general access
checking mechanism deep in its guts in addition to strong encapsulation; quite 
the opposite.


— Ron



On 3 Aug 2021, at 10:44, Peter Firmstone  wrote:

Thanks Ron, reply inline.

On 3/08/2021 6:48 pm, Ron Pressler wrote:

On 3 Aug 2021, at 06:48, Peter Firmstone 
  wrote:


We can still use these without an SM, Policy or Permissions for authorization 
decisions, as mentioned previously I'd replace the inherited thread context 
with an unprivileged context, and also allow the stack walk to be disabled for 
people only using Subject.



I think what you mean is that you can envision using the same API points for a 
different, but reasonably similar
role to the one they have. But that would mean changing the behaviour of 
existing classes, possibly making some
final classes non-final, in non-trivial ways.


I'd limit changes to:

• Make the stack walk optional (via command line argument to disable 
it).
• Remove Thread's inherited context, replace it with an unprivileged 
context.
This would allow us to use the API for virtual threads, eg to obtain Subject 
credentials to authenticate TLS connections.

It also means that for someone implementing guard checks, that these only need 
check the thread stack back to the last doPrivileged call, or the start of the 
thread, in the latter case it will have no privileges.  It fixes the viral 
permission check problem, usually doPrivileged calls are short and sweet.

It may require the addition of doPrivileged calls where they're currently 
missing (and should have been used), where they've been responsible for viral 
permission checks.


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



The plan is to degrade these into no-ops until such time as most of those 
usages disappear, not to imbue
those lines of code with new meaning. The actual removal of the API elements 
might be a long way off,
but, becoming no-ops before then, the JDK and libraries will be free to remove 
those usages.


No new meanings, the same as they have now is sufficient, just we leave the 
granularity of the checks to the developers of guards and provide a means by 
which guards can be registered for common check points that developers request 
(perhaps via a poll), rather than all existing permission check points.  
Keeping in mind that we are not trying to isolate code, but perform 
authorization access checks, as well as provide credentials for authentication.

For example, if someone is only concerned with stopping the JVM from exiting, 
then they only implement a guard for that particular hook, the actual code that 
needs to call System::exit, then calls a doPrivileged method before doing so.  
The guard need only check the domain on the stack is the one it expects, which 
could be based on Principal, CodeSource, Module or ClassLoader etc, they may 
also chose to implement something more complex.

Someone

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


Wow, thanks Andrew,

There's certainly some complexity there, I appreciate your guidance.

Regards,

Peter.

On 3/08/2021 7:11 pm, Andrew Dinn wrote:

On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for 
line numbers in code, for exceptions etc, how are these affected when 
instrumenting?


For Byteman I use ASM to inject bytecode sequences into methods 
without any (significant) modification to existing bytecodes. ASM 
successfully adjusts line number info to allow for the injected code 
without the need for my agent to take any action.


I also add extra exception handling around injected regions and 
propagate exceptions through enclosing regions to an outer handler. 
ASM updates the exception table according to where the method visitor 
notifies new try and catch region boundaries while retaining the 
regions determined by existing notifications.


ASM provides mechanism for more complex cases. If you are rewriting 
existing bytecodes or exception regions then you can use the ASM 
visitor pattern to process and then renotify both line numbers and try 
catch boundaries as you visit the bytecode stream. Of course, the 
logic of how to do that can be as complex as (or more so than) the 
rewrite logic.


n.b. Remapping exception regions at load time is tricky for two 
reasons. Firstly, you cannot afford to load exception classes to 
investigate the exception class hierarchy without losing the 
opportunity to transform the exception class's bytecode. So, you have 
to identify exception shadowing by parsing the bytecode as a resource 
to establish exception super relationships. Secondly, if you tinker 
with or inject extra try regions you need to a) ensure they are 
properly nested inside containing try regions b) make sure that new  
exception exit paths out of synchronized regions include monitorexits.


regards,


Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

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


Thanks Ron, reply inline.

On 3/08/2021 6:48 pm, Ron Pressler wrote:



On 3 Aug 2021, at 06:48, Peter Firmstone  wrote:


We can still use these without an SM, Policy or Permissions for authorization 
decisions, as mentioned previously I'd replace the inherited thread context 
with an unprivileged context, and also allow the stack walk to be disabled for 
people only using Subject.


I think what you mean is that you can envision using the same API points for a 
different, but reasonably similar
role to the one they have. But that would mean changing the behaviour of 
existing classes, possibly making some
final classes non-final, in non-trivial ways.


I'd limit changes to:

1. Make the stack walk optional (via command line argument to disable it).
2. Remove Thread's inherited context, replace it with an unprivileged
   context.

This would allow us to use the API for virtual threads, eg to obtain 
Subject credentials to authenticate TLS connections.


It also means that for someone implementing guard checks, that these 
only need check the thread stack back to the last doPrivileged call, or 
the start of the thread, in the latter case it will have no privileges.  
It fixes the viral permission check problem, usually doPrivileged calls 
are short and sweet.


It may require the addition of doPrivileged calls where they're 
currently missing (and should have been used), where they've been 
responsible for viral permission checks.





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


The plan is to degrade these into no-ops until such time as most of those 
usages disappear, not to imbue
those lines of code with new meaning. The actual removal of the API elements 
might be a long way off,
but, becoming no-ops before then, the JDK and libraries will be free to remove 
those usages.


No new meanings, the same as they have now is sufficient, just we leave 
the granularity of the checks to the developers of guards and provide a 
means by which guards can be registered for common check points that 
developers request (perhaps via a poll), rather than all existing 
permission check points.  Keeping in mind that we are not trying to 
isolate code, but perform authorization access checks, as well as 
provide credentials for authentication.


For example, if someone is only concerned with stopping the JVM from 
exiting, then they only implement a guard for that particular hook, the 
actual code that needs to call System::exit, then calls a doPrivileged 
method before doing so.  The guard need only check the domain on the 
stack is the one it expects, which could be based on Principal, 
CodeSource, Module or ClassLoader etc, they may also chose to implement 
something more complex.


Someone else may only be concerned with network connections, so they 
only implement and register a guard for that.


So basically we don't dictate how to implement guards or policy, we just 
leave enough in place, to ensure that a minimalist authorization access 
control api is common among all implementations on all Java versions.


It is suitable, for Subject's only or code and Subject's.

The doPrivileged call simply indicates the code is requesting to do 
something that might be privileged, or needs to provide credentials for 
authentication, as it does now, but it's the light version of the stack 
walk, if doPrivileged is not called, then the context will have an 
unprivileged domain on the stack (that initialized when Thread was 
created.).


It's also possible to register guards that do fine grained permission 
checks, similar to the way Java does now.


Then there's the use case, or registering no guards at all, and 
disabling the stack walk, and only using the api to obtain and preserve 
Subject credentials for authentication.


You can trust me on this one, I'm experienced with the current API and 
have pushed it to all sorts of limits.


Cheers,

Peter.

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

2021-08-03 Thread Andrew Dinn


On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for line 
numbers in code, for exceptions etc, how are these affected when 
instrumenting?


For Byteman I use ASM to inject bytecode sequences into methods without 
any (significant) modification to existing bytecodes. ASM successfully 
adjusts line number info to allow for the injected code without the need 
for my agent to take any action.


I also add extra exception handling around injected regions and 
propagate exceptions through enclosing regions to an outer handler. ASM 
updates the exception table according to where the method visitor 
notifies new try and catch region boundaries while retaining the regions 
determined by existing notifications.


ASM provides mechanism for more complex cases. If you are rewriting 
existing bytecodes or exception regions then you can use the ASM visitor 
pattern to process and then renotify both line numbers and try catch 
boundaries as you visit the bytecode stream. Of course, the logic of how 
to do that can be as complex as (or more so than) the rewrite logic.


n.b. Remapping exception regions at load time is tricky for two reasons. 
Firstly, you cannot afford to load exception classes to investigate the 
exception class hierarchy without losing the opportunity to transform 
the exception class's bytecode. So, you have to identify exception 
shadowing by parsing the bytecode as a resource to establish exception 
super relationships. Secondly, if you tinker with or inject extra try 
regions you need to a) ensure they are properly nested inside containing 
try regions b) make sure that new  exception exit paths out of 
synchronized regions include monitorexits.


regards,


Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

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




On 3/08/2021 6:31 pm, Ron Pressler wrote:



On 3 Aug 2021, at 02:30, Peter Firmstone  wrote:


I am still hopeful that OpenJDK might create some hooks for us and keep the 
AccessController, AccessControlContext and Subject.doAs methods to make 
supporting all Java versions easier.

When I mentioned “hooks” I was referring to something along the lines of a 
callback when a file is
accessed.



Can you elaborate?   A Runnable, similar to registering a shutdown hook?





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

When you transform a class, you basically replace its content with new content, 
so the short answer is
that what happens to line numbers is whatever you want. If you’re using ASM for 
your transformation and
ignore line numbers, which ASM represents as a kind of no-op instructions, then 
what would usually happen
is that if original instruction X is mapped to line N and when transforming the 
stream you replace X with
YXZ, then all of YXZ will remain mapped to line N.


Ok, Currently my experience with ASM is finding dependencies, and 
unpacking the pack200 format. I hadn't stopped to consider what it might 
do to line numbers.


Cheers,

Peter.

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

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


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

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

We can still use these without an SM, Policy or Permissions for 
authorization decisions, as mentioned previously I'd replace the 
inherited thread context with an unprivileged context, and also allow 
the stack walk to be disabled for people only using Subject.


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


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


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


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

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


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

--
Regards,
 
Peter





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

Thanks Ron,

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


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


I am still hopeful that OpenJDK might create some hooks for us and 
keep the AccessController, AccessControlContext and Subject.doAs 
methods to make supporting all Java versions easier. Also replacing 
thread inherited context, with an unprivileged context would be good 
too.  Then remove all the permission implementations and we could use 
the hooks we need.  The hooks could simply be an empty static method 
that's not subject to change, so we can instrument it with our own 
implementation and it gets optimized out at runtime if not used by 
hotspot.  Clearly if there are alternative mechanisms available from 
the command line that we don't need to dynamically enable, then they 
are preferable to adding clutter to policy files.   The existing 
policy provider can be removed, so we can strip it down to just the 
essential minimum components, which removes much of the testing 
required by OpenJDK.


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


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


Regards,

Peter.

On 2/08/2021 9:00 pm, Ron Pressler wrote:
Our path to making Java more secure is, indeed, similar to what 
you’re proposing.


The general direction is that the application, rather than the 
libraries, will have the final say on security-sensitive capabilities.
Just as strong encapsulation is now on by default, other things, such 
as native code, some dynamic Agent capabilities, and
perhaps others, will likely require explicit permission by the 
application on the command line. I don’t know the details about
management, but I believe that remote management requires explicit 
permission already.


I am not aware, however, of plans to restrict class loading. The idea 
is that code is trusted to do what it says it does, and
what’s restricted is the ability to manipulate it (without 
permission) to do something else

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

Thanks Ron,

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

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

I am still hopeful that OpenJDK might create some hooks for us and keep
the AccessController, AccessControlContext and Subject.doAs methods to
make supporting all Java versions easier. Also replacing thread
inherited context, with an unprivileged context would be good too. Then
remove all the permission implementations and we could use the hooks we
need. The hooks could simply be an empty static method that's not
subject to change, so we can instrument it with our own implementation
and it gets optimized out at runtime if not used by hotspot. Clearly if
there are alternative mechanisms available from the command line that we
don't need to dynamically enable, then they are preferable to adding
clutter to policy files. The existing policy provider can be removed,
so we can strip it down to just the essential minimum components, which
removes much of the testing required by OpenJDK.

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

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

Regards,

Peter.

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

Our path to making Java more secure is, indeed, similar to what you’re
proposing.

The general direction is that the application, rather than the libraries, will
have the final say on security-sensitive capabilities.
Just as strong encapsulation is now on by default, other things, such as native
code, some dynamic Agent capabilities, and
perhaps others, will likely require explicit permission by the application on
the command line. I don’t know the details about
management, but I believe that remote management requires explicit permission
already.

I am not aware, however, of plans to restrict class loading. The idea is that
code is trusted to do what it says it does, and
what’s restricted is the ability to manipulate it (without permission) to do
something else through transformation or
circumvention of its declared API.

The default security policy today is already more restrictive than it was a
couple of versions ago, and we expect it to become
even more restrictive.

— Ron

On 2 Aug 2021, at 11:33, Peter Firmstone wrote:

Hello Andrew,

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

I'm assuming that during the process of removal of security manager, any
external ports or process hooks that we can only turn off now by not granting a
permission will be replaced by a command line property or something similar?
Eg, Agents, Management, etc. If this is the case, it would be nice if they were
set to off by default, such that they needed to be enabled from the command
line. It's a suggestion. So configuration is secure by default. Eg, similar
to how OpenBSD is configured secure by default, is that something RedHat does?
I used RedHat back in the 90's, it was my first Linux distro, on sparc. :)

For example, the permissions granted in this policy file:

https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new__;!!ACWV5N9M2RV99hQ!cVJkwzysH02ZFZWT3rnO_o5viWUCBTm9nnM50QaJ5G9hsg9B3p2naDVYknIrqSNURQ$
Ensure that anything that isn't specifically granted, is switched off, eg
agents, management, etc.

This file is generated by a policy writing tool, the comments in the policy
file, indicate the tests that were run to generate the policy. It's important
to note that we aren't using sandboxing, or isolation, we are simply running
with privileges we don't require switched off. All network entry points to
the JVM require authentication and classes loaded, or data parsed requires
authentication first.

In my software without SM, authentication isn't required, and there are no
defenses against parsing un-trusted data or downloading and loading malicious
classes. Although you've made it clear, you think this is a /special case/ and
/special loss/ you needn't concern yourself with and that's fine, you've made
your point.

In future it will not be possible to switch these features off using policy
files, so I imagine that OpenJDK must be considering alternative methods to
switch off features that may be security sensitive?

We already know de-serialization can be switched off from the

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


Hello Andrew,

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

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


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


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

In JGDMS without SM, at least the following must be addressed to 
maintain security:


1. TLS and Kerberos connections cannot be established.  (My software is
   littered with doPrivileged calls that preserve the Subject, we don't
   have anon TLS connections, we require client certificates).
2. All remote connections are authorized to load classes.
3. All remote connections are authorized to perform deserialization.

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


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


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


Having established that OpenJDK is not yet willing to compromise, I have 
been attempting to create an authorization layer using Agents, so that I 
can restore perimeter security following the removal of SM and support 
future versions of Java.   It is my hope that either I will be 
successful in recreating an authorization layer, or that enough people 
come forward and OpenJDK decides there are enough affected developers to 
find a compromise that either makes migration practical, or less expensive.


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


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


Thank you.

Peter.

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

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

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


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


I'm assuming that during the process of removal of security manager, 
any external ports or process hooks that we can only turn off now by 
not granting a permission will be replaced by a command line property 
or something similar? Eg, Agents, Management, etc. If this is the 
case, it would be nice if they were set to off by default, such that 
they needed to be enabled from the command line.  It's a suggestion. 
. . .
They might be or they might not be replaced -- and,

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

2021-08-02 Thread Andrew Dinn


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

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


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


I'm assuming that during the process of removal of security manager, any 
external ports or process hooks that we can only turn off now by not 
granting a permission will be replaced by a command line property or 
something similar?  Eg, Agents, Management, etc. If this is the case, it 
would be nice if they were set to off by default, such that they needed 
to be enabled from the command line.  It's a suggestion. . . .
They might be or they might not be replaced -- and, indeed, you are 
welcome to help the project to make that a possibility. However, even if 
they were not replaced or enabled as default behaviours the platform 
would not fail to be 'secure by default'. At worst, it might be lacking 
belt and braces when it comes to available means for enforcing some 
specific forms of control over execution -- controls that can be used to 
resolve some security problems, but not exclusively. Yet, you keep using 
language that implies the loss of the security manager is a significant 
threat to the security of OpenJDK/Java.


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


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


regards,


Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

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

2021-08-02 Thread Andrew Haley

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

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

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

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


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.

2021-08-02 Thread Andrew Dinn


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

I'm working on the assumption that OpenJDK will close any
external holes currently defended by permission checks.  It would
be good if the JDK was secure by default, with properties
required to be set for allowing such things as agents,
management, parsing xml and serialization.


You need to stop repeating this canard. There is no absolute need
for OpenJDK to retain a security mechanism to deal with problems
that for almost every use case are better solved by using
non-OpenJDK alternatives (such as OS security measures). Indeed,
it's the other way round: there is an imperative for the project to
spend precious resources on alternative capabilities (not
necessarily security related).


Sorry, as another open source project affected by the stupid JEP 411
desaster I would like to fully confirm to EVERYTHING that Peter said.
It is not a canard, it is the reality and I am really disappointed
what happened.


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


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


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


regards,


Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

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


Thanks Florian,

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

JSR-121: Java Application Isolation API Specification.

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

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


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


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


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


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


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

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

};

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


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


Regards,

Peter.

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

* Peter Firmstone:


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

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

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

   Java and Speculative Execution Vulnerabilities
   

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

Thanks,
Florian

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

2021-08-02 Thread Florian Weimer

* Peter Firmstone:

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

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

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

  Java and Speculative Execution Vulnerabilities
  

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

Thanks,
Florian

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