subject:"Re\: JEP411\: Missing use\-case\: Monitoring \/ restricting libraries"

Studies, experts, meetings and academics, without practical application 
of the principle of least privilege, these are meaningless.  I hope 
someone remembered to bring tea and scones.


My point is nothing gets done without workers.  It's the Pareto 
Principle or 80:20 rule.   Li Gong may have been an academic at that 
time, but he also got down to business and got the work done too, today 
he's a CEO.  How many of your experts are CEO's?   Very smart people 
study in academia, but they spread their wings and apply what they've 
learned, and in doing so learn new lessons and truly understand, then 
they are no longer academics, some retreat to the safety of the academic 
world.   The best lecturers were retiree's from the real world of 
application, well lets just leave it at that.


No matter how expert you are at A, doesn't qualify you to comment on B, 
when you've had limited or no experience in B.


I have demonstrated practical application and arguments based on 
examples and implementations.


Yes, NPV analysis indicates the best option is to not upgrade. This is 
the least harm, lowest cost option, in your words, I can't have both A 
and B, so I've chosen A.


Abandoning the principles of least privilege will significantly increase 
the consequences of a security breach.


The Australian native bee, has a unique defense system:

1. Guard bee's are positioned at the hive entrance to authenticate the
   bees entering the hive and will defend against intruders, battling
   until death.
2. If an intruder makes it past the guard bees, the bees inside the
   hive use resin to glue the intruders to the hives internal
   structures, intruders are rendered immobile and cannot move. Then
   the bees continue about their daily tasks ignoring the intruders
   until they die, then a bee on cleanup duty removes them and discards
   their carcasses outside the hive.

This is the principle of least privilege, to render the attacker 
harmless after breaching the perimeter, also it helps maintain perimeter 
defenses by reducing the attackers ability to pull them down, in doing 
so, it adds to the effectiveness of perimeter defenses.


I wonder how long the bee's would survive if they stopped immobilizing 
intruders and let them eat their larvae?


No it makes Bee's less secure, not more.

I get it that many developers don't care about security, at least until 
they wish they had.   Bee's get it, I wonder why many developers don't?


I get it that OpenJDK didn't know that SecurityManager infrastructure 
actually worked and thought that no one was using it, maybe that's why 
they did nothing to improve it, because they never believed in it in the 
first place, it was an annoying feature that got in the way of getting 
something else done.


https://github.com/openjdk/jdk/blame/master/src/java.base/share/classes/java/lang/SecurityManager.java

https://github.com/openjdk/jdk/blame/master/src/hotspot/share/prims/jvm.cpp

https://github.com/openjdk/jdk/blame/master/src/java.base/share/classes/java/security/AccessController.java

https://github.com/openjdk/jdk/blame/master/src/java.base/share/native/libjava/AccessController.c

I accept it's being removed, I just want you to understand just what it 
is you're removing, so you understand that this isn't going to be easy 
for you either, the consequences await you at a later date, I can see 
them, but you cannot because you cannot foresee what's unknown to you.


I hope that next time, more thorough research is done before making such 
hasty decisions.  Even experts make mistakes.  More time needs to be 
spent on community consultation, but then maybe not if its not something 
you care about.


With respect I think it's time to retire this conversation, I'm sure we 
both have other things we need to do.  Judging by the conversation, 
people haven't had time to review the practical examples submitted, or 
aren't interested, I'll remain available should there be interest.


Regards,

Peter.

On 22/05/2021 11:12 am, Ron Pressler wrote:

Let me be very clear: the proposers of this JEP, some of whom have worked on 
the Security Manager for the
last twenty years, strongly believe that not only will its removal not harm 
Java’s security, but considerably
improve it, as do the maintainers of other platforms who have decided to either 
not try to offer security
through the deep stack-dependent sandbox model or did but have since also 
removed it. Their view is backed
by security experts, both those working on OpenJDK and outside it.

While I seriously hope you don’t actually believe a decision was made before 
publication, it is also obviously
true that this wouldn’t have been proposed in the first place without *a lot* 
of thought, study and discussion.
The proposal was made only after it was clear this was a very, *very* strong 
case, and that the chances of finding
fault with it are low. It wasn’t put up after someone just had an idea. It is, 
therefore, not entirely
surprising

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

Let me be very clear: the proposers of this JEP, some of whom have worked on 
the Security Manager for the
last twenty years, strongly believe that not only will its removal not harm 
Java’s security, but considerably
improve it, as do the maintainers of other platforms who have decided to either 
not try to offer security
through the deep stack-dependent sandbox model or did but have since also 
removed it. Their view is backed
by security experts, both those working on OpenJDK and outside it.

While I seriously hope you don’t actually believe a decision was made before 
publication, it is also obviously
true that this wouldn’t have been proposed in the first place without *a lot* 
of thought, study and discussion.
The proposal was made only after it was clear this was a very, *very* strong 
case, and that the chances of finding
fault with it are low. It wasn’t put up after someone just had an idea. It is, 
therefore, not entirely 
surprising that no one has been able to give any relevant arguments against it. 
Clearly, you have had far less 
time to think about it, but I can’t seem to steer your arguments in a direction 
that’s relevant to what is actually 
the issue.

I understand you’re invested in the Security Manager and that its removal would 
impose real costs on you. I am even
willing to believe that you actually believe that, despite what studies show, 
despite what experts say, despite
what the developers of Java say, despite what the developers of *all* other 
mainstream software platforms with 
an emphasis on security, both new and old —- from .NET to WebAssembly —- have 
concluded after decades of experience, 
that the Security Manager is not only the best way to secure Java but 
apparently the only one. Maybe you’re right 
and those others are wrong, but please accept that we all want to improve 
Java’s security, we just disagree with you 
on the best way to do it.

Yes, additional security measures, whatever they are, would provide additional 
security. But if the choice is 
between measure A and measure B -— you *can’t* have both —- you pick the one 
that is *more* effective per cost. 
None of your arguments so much as glance in that direction, and they don’t 
acknowledge the fact that Java security 
would be hardly affected by the Security Manager’s removal even without better 
protection elsewhere for the simple 
reason that it is hardly ever installed, including on the most 
security-critical applications, whose defences 
apparently aren’t so feeble even today. In any event, if the question is, do we 
want a perimeter fence and security 
cameras *XOR* locks on all room doors, the argument that they provide security 
through different mechanisms so we 
should have both completely misunderstands the question. I am also confused by 
your point about multi-user
applications. Of course different users have different access, but surely you 
are aware that very few applications
do that using the Security Manager, which isn’t needed —- and is rarely used -— 
for that purpose.

Short of making relevant arguments, I would urge you again to focus on 
suggestions to reduce the harm this proposal 
would cause you.

— Ron

> On 22 May 2021, at 00:17, Peter Firmstone  wrote:
> 
> I had hoped by end of this discussion, that there would at least be an 
> understanding of what OpenJDK is so hastily choosing to destroy.
> 
> Once it is gone, it will be irretrievable, it will never be possible to lock 
> down the JVM so securely again.
> 
> 
> On 21/05/2021 11:06 pm, Ron Pressler wrote:
>> 
>>> On 21 May 2021, at 12:52, Peter Firmstone  
>>> wrote:
>>> 
>>> It's quite clear this will be pushed through anyway,
>>> 
>> No, not *anyway*, but given the fact that the community consists of millions 
>> of users, this
>> proposal has been well-publicised,
> 
> 
> I discovered the proposal on the 11th of the May on a mailing list I was 
> subscribed to and I almost missed it.   Yes, it will be pushed through 
> regardless, clearly the decision was made before publication.   Everyone saw 
> applets coming, if the developers were serious about supporting applets, they 
> would have designed a stripped down subset of Java, a JVM specifically suited 
> that task which, didn't include things like XML or serialization.
> 
> Just think, Applets were killed because of their atrocious security.   How 
> ironic.
> 
> 
>>> The granularity is not arbitrary, you said by class, which is incorrect.
>>> 
>>> Granularity is by a combination of one or more of the following:
>>> 
>>> • ProtectionDomain
>>> • CodeSource
>>> • Code signers
>>> • ClassLoader
>>> • Principals.
>> What I said is correct. Assigning a ProtectionDomain to a class is possible, 
>> though not to a method
>> (certainly not in code you can’t modify). In fact, ProtectionDomain is 
>> defined as “a set of classes,”
>> i.e. class granularity. In particular, that is the granularity that 
>> instrumentation with doPrivileged
>> aims to

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

I had hoped by end of this discussion, that there would at least be an 
understanding of what OpenJDK is so hastily choosing to destroy.


Once it is gone, it will be irretrievable, it will never be possible to 
lock down the JVM so securely again.



On 21/05/2021 11:06 pm, Ron Pressler wrote:



On 21 May 2021, at 12:52, Peter Firmstone  wrote:

It's quite clear this will be pushed through anyway,


No, not *anyway*, but given the fact that the community consists of millions of 
users, this
proposal has been well-publicised,



I discovered the proposal on the 11th of the May on a mailing list I was 
subscribed to and I almost missed it.   Yes, it will be pushed through 
regardless, clearly the decision was made before publication.   Everyone 
saw applets coming, if the developers were serious about supporting 
applets, they would have designed a stripped down subset of Java, a JVM 
specifically suited that task which, didn't include things like XML or 
serialization.


Just think, Applets were killed because of their atrocious security.   
How ironic.




The granularity is not arbitrary, you said by class, which is incorrect.

Granularity is by a combination of one or more of the following:

• ProtectionDomain
• CodeSource
• Code signers
• ClassLoader
• Principals.

What I said is correct. Assigning a ProtectionDomain to a class is possible, 
though not to a method
(certainly not in code you can’t modify). In fact, ProtectionDomain is defined 
as “a set of classes,”
i.e. class granularity. In particular, that is the granularity that 
instrumentation with doPrivileged
aims to address, and that is one of the Security Manager’s most defining 
features.


It may be possible to assign a ProtectionDomain, to a single class, but 
that doesn't make your assertions correct, you should be quoting common 
use cases, I have never seen an example of assigning permissions to a 
single class, besides, it requires a dynamic policy to do that, and Java 
doesn't have one by default, so you can't use PolicyFile to assign it 
permissions.   Maybe you could use it to encapsulate ObjectInputStream 
with no permissions, then no one could grant it permissions, so that 
would be useful for Security.  It doesn't change class resolution or 
visibility. But OpenJDK didn't do that, why not?



What use case would there be to assign a ProtectionDomain to a method?

Just use a permission check in the method, or wrap a sensitive class 
with a decorator before publication:


http://svn.apache.org/viewvc/river/permission_delegates/src/main/java/org/apache/river/api/delegates/package.html?view=markup

But these are corner cases.

More useful cases are for isolation, such as JEE.




Restricting access by principal at the application level does not require the 
Security Manager, so that
part is irrelevant, and, in fact, not only Principal, but also Permission, and 
even CodeSource and
ProtectionDomain are *not* being proposed for terminal deprecation or even 
deprecation by this JEP.



I guess your use case is a desktop application running in a single process?

What about a multi user server application running in a single 
process?   Now we have to spawn multiple processes for each user, that's 
hardly efficient or performant is it?






I would like to understand this pain that is being caused to a far greater 
number of people?   So far information has been scarce and it seems more of an 
excuse, as it's very light on detail.  I would guess it's the pain of having to 
update policy files and making sure tests pass with security enabled.

The pain is that the high cost of maintaining the Security Manager comes at the 
expense of
other security measures that, we believe, provide far more security value to 
the Java ecosystem
as a whole.



Such as?



I think the results of locking down the JVM to principles of least privilege 
are totally worth it and a saleable commodity in the current global environment.

I absolutely accept the principle of least privilege. I do not accept that the 
marginal cost/benefit
of applying it at class granularity yields its best application.



I agree that there's little value for class granularity, but you are 
applying a corner case that although possible, is never applied in 
practice, and applying it with a broad brush, then using it as an 
argument against, please stop making this false assertion.   Just 
because you can do something, doesn't mean that you should.   Just 
because you can walk in front of a passing train, doesn't mean you 
should sir.


There is however a significant benefit for applying the principle of 
least privilege.


It can be assigned to Principal and Code signer granularity, that's 
actually quite coarse grained.  It's very flexible, unlike white listing 
Serializable classes.



Sure, theoretical things might, but there's no implementation in existence.  It 
has been quite affordable for me, so I wish to understand this pain,

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 21 May 2021, at 12:52, Peter Firmstone  wrote:
> 
> It's quite clear this will be pushed through anyway,
> 

No, not *anyway*, but given the fact that the community consists of millions of 
users, this
proposal has been well-publicised, only very few people have voiced objections, 
fewer
still who have voiced objections actually use the Security Manager for 
security, and no
one has yet made a single relevant argument, accepting this proposal so far 
seems like the
only reasonable outcome, perhaps with accommodations to offer alternatives for 
certain
use-cases. 

> so there's no harm in sharing the information, unless you don't have a list, 
> in which case it's not possible to share something you don't have.

I have already linked to one empirical study, I know that further scans of 
public repositories
have been conducted but *I* don’t have the data; those who do are free to share 
it if they
think there is no harm in that (although I think there might be).

> 
> The granularity is not arbitrary, you said by class, which is incorrect.
> 
> Granularity is by a combination of one or more of the following:
> 
>   • ProtectionDomain
>   • CodeSource
>   • Code signers
>   • ClassLoader
>   • Principals.

What I said is correct. Assigning a ProtectionDomain to a class is possible, 
though not to a method 
(certainly not in code you can’t modify). In fact, ProtectionDomain is defined 
as “a set of classes,”
i.e. class granularity. In particular, that is the granularity that 
instrumentation with doPrivileged 
aims to address, and that is one of the Security Manager’s most defining 
features.

Restricting access by principal at the application level does not require the 
Security Manager, so that 
part is irrelevant, and, in fact, not only Principal, but also Permission, and 
even CodeSource and 
ProtectionDomain are *not* being proposed for terminal deprecation or even 
deprecation by this JEP.

> 
> I would like to understand this pain that is being caused to a far greater 
> number of people?   So far information has been scarce and it seems more of 
> an excuse, as it's very light on detail.  I would guess it's the pain of 
> having to update policy files and making sure tests pass with security 
> enabled.

The pain is that the high cost of maintaining the Security Manager comes at the 
expense of
other security measures that, we believe, provide far more security value to 
the Java ecosystem
as a whole.

> 
> I think the results of locking down the JVM to principles of least privilege 
> are totally worth it and a saleable commodity in the current global 
> environment.

I absolutely accept the principle of least privilege. I do not accept that the 
marginal cost/benefit
of applying it at class granularity yields its best application.

> 
> Sure, theoretical things might, but there's no implementation in existence.  
> It has been quite affordable for me, so I wish to understand this pain, 
> because I currently don't, I'm already using the latest encryption, static 
> analysis, secure coding practices, validating input, sanitizing data etc.

There are, though. Here are some: JFR, the module system, crypto protocols and 
ad-hoc mechanisms for 
specific vulnerable components (serialization, XML etc.). Maintaining the 
Security Manager comes at their 
expense -- some require urgent improvements like adding more events to JFR and 
closing down gaps in the 
module system’s defences -- and we believe investing in them has a better 
security ROI overall.

> 
> Other techniques that are yet to be developed.   OpenJDK is deprecating 
> SecurityManager prior to the implementation of it's replacement, a little 
> more notice would have been nice.   I'm ready for you to deprecate 
> Serialization, we saw that coming, but this is just completely unexpected out 
> of left field.

First, any deprecation proposal could be said to be unexpected until it is 
proposed. But that is why 
we have a deprecation policy that makes the process gradual and gives people 
time to adjust. Second, I
don’t think this is "out of left field" at all. The writing on the wall was 
pretty clear when, after twenty-five 
years, few projects use the Security Manager and few libraries are properly 
instrumented for it, other platforms 
have decided not to adopt a similar model, and those few that have have already 
abandoned it some years ago.

> 
> Currently it is the only possible and practicable means that has been 
> implemented, I'm sure something better will come along, but everything better 
> is just theoretical at this time.
> 
> Nothing else is even remotely capable of locking the JVM down this securely.

I‘m sure you're responding to *some* argument, but not to mine. Any additional 
security measure would 
“lock something down” more than not having it. Whether or not it is worthwhile 
depends on the marginal 
benefit vs. the marginal cost. I believe that the marginal benefit for the 
marginal cost of the

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries



On 21/05/2021 9:14 pm, Ron Pressler wrote:



On 21 May 2021, at 11:29, Peter Firmstone  wrote:


Can you share this list please?   If I see anything missing I can add it for 
you.

No, because this might give the false impression that this is a debate.



It's quite clear this will be pushed through anyway, so there's no harm 
in sharing the information, unless you don't have a list, in which case 
it's not possible to share something you don't have.






So I'm restricting permissions granted to only those required to perform the 
intended tasks of the software,  restricted even to a subset of which that 
software is capable, and you say it is not the principle of least privilege?

That is not what the Security Manager is doing, though. It is able to assign 
“least privilege” to some
arbitrary level of granularity and not others.



The granularity is not arbitrary, you said by class, which is incorrect.

Granularity is by a combination of one or more of the following:

1. ProtectionDomain
2. CodeSource
3. Code signers
4. ClassLoader
5. Principals.


How do you critique something if you don't understand how it works?

I stand by what I said. “X granularity” means up-to and no-less-than X, and 
assigning software privileges
per user at the application level does not require the Security Manager. I 
understand that your particular
codebase does use the Security Manager to assign all software privileges, and 
that removing it might require
costly changes to your codebase, but that is not the most common way, and it is 
certainly not the *only*
way this is done in Java codebases. I absolutely sympathise with the pain this 
proposal would cause you,
but please sympathise with the pain that not accepting it would cause what we 
believe is a far greater
number of people, and don’t try to universalise your particular situation.



You said class level granularity, which is incorrect.   True, it is not 
possible to upgrade, I guess you could say that's painful, as it will be 
for everyone else caught up by it.


I would like to understand this pain that is being caused to a far 
greater number of people?   So far information has been scarce and it 
seems more of an excuse, as it's very light on detail.  I would guess 
it's the pain of having to update policy files and making sure tests 
pass with security enabled.


I perform all tests with security enabled, because it will work if it 
isn't anyway.   Policy files are easily regenerated using tools.


What other pain is there?

I think the results of locking down the JVM to principles of least 
privilege are totally worth it and a saleable commodity in the current 
global environment.





So you are mistaken about what it is that I am critiquing. I am not critiquing 
the operation of the
Security Manager nor am I saying that it is incapable of preventing certain 
attacks. I am critiquing the
claim that no other technique can achieve better security more cheaply.



Sure, theoretical things might, but there's no implementation in 
existence.  It has been quite affordable for me, so I wish to understand 
this pain, because I currently don't, I'm already using the latest 
encryption, static analysis, secure coding practices, validating input, 
sanitizing data etc.




  I am saying that the marginal utility
if the Security Manager divided by its marginal cost is lower than the marginal 
utility divided by the marginal
cost of other security techniques.



Other techniques that are yet to be developed.   OpenJDK is deprecating 
SecurityManager prior to the implementation of it's replacement, a 
little more notice would have been nice.   I'm ready for you to 
deprecate Serialization, we saw that coming, but this is just completely 
unexpected out of left field.





We have no argument over the value of security or that of the principle of 
least privilege.
We merely disagree over whether the Security Manager specifically is the best 
possible means to those ends.



Currently it is the only possible and practicable means that has been 
implemented, I'm sure something better will come along, but everything 
better is just theoretical at this time.


Nothing else is even remotely capable of locking the JVM down this 
securely.






I don't wish to publicly show that I doubt your credibility, but you are making 
it difficult for me not to sir.  It is your user base you need to convince, so 
far, you are not very convincing.


I am sorry, but that not everyone would be convinced by every argument we make 
is something we take as a given.
It is the duty of those who disagree with proposals put forth by the 
maintainers to convince the maintainers,
not the other way around. I am trying to help you focus you on arguments that 
would be relevant. They are:


1. The *current* value the Security Manager to the Java ecosystem is high, 
evidenced by the great number of
companies that employ it for software security.

2. The Security Manager has the highest ROI compared

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 21 May 2021, at 11:29, Peter Firmstone  wrote:
> 
> 
> Can you share this list please?   If I see anything missing I can add it for 
> you.

No, because this might give the false impression that this is a debate. In a 
community
of millions, almost no decision will be universally accepted. So the goal here 
is to collect
information and have people try to convince the maintainers, not the other way 
around.

This is the only way to not get into interminable debates and to get things 
done. At the end of 
the day, either you trust that our intentions is to make Java more secure and 
more successful or 
you don’t. We hope that the majority of Java users do.

> 
> So I'm restricting permissions granted to only those required to perform the 
> intended tasks of the software,  restricted even to a subset of which that 
> software is capable, and you say it is not the principle of least privilege?

That is not what the Security Manager is doing, though. It is able to assign 
“least privilege” to some
arbitrary level of granularity and not others. Other techniques apply the same 
principle at different
granularities.

> 
> How do you critique something if you don't understand how it works?

I stand by what I said. “X granularity” means up-to and no-less-than X, and 
assigning software privileges
per user at the application level does not require the Security Manager. I 
understand that your particular
codebase does use the Security Manager to assign all software privileges, and 
that removing it might require
costly changes to your codebase, but that is not the most common way, and it is 
certainly not the *only*
way this is done in Java codebases. I absolutely sympathise with the pain this 
proposal would cause you,
but please sympathise with the pain that not accepting it would cause what we 
believe is a far greater
number of people, and don’t try to universalise your particular situation.

So you are mistaken about what it is that I am critiquing. I am not critiquing 
the operation of the 
Security Manager nor am I saying that it is incapable of preventing certain 
attacks. I am critiquing the 
claim that no other technique can achieve better security more cheaply. I am 
saying that the marginal utility 
if the Security Manager divided by its marginal cost is lower than the marginal 
utility divided by the marginal 
cost of other security techniques.

We have no argument over the value of security or that of the principle of 
least privilege.
We merely disagree over whether the Security Manager specifically is the best 
possible means to those ends.

> 
> I don't wish to publicly show that I doubt your credibility, but you are 
> making it difficult for me not to sir.  It is your user base you need to 
> convince, so far, you are not very convincing.
> 

I am sorry, but that not everyone would be convinced by every argument we make 
is something we take as a given.
It is the duty of those who disagree with proposals put forth by the 
maintainers to convince the maintainers,
not the other way around. I am trying to help you focus you on arguments that 
would be relevant. They are:

1. The *current* value the Security Manager to the Java ecosystem is high, 
evidenced by the great number of 
   companies that employ it for software security.

2. The Security Manager has the highest ROI compared to all other approaches.

Our assumption is that both 1 and 2 are false. If you’d like to convince the 
maintainers, support one or both 
of these arguments. Any other is irrelevant, because true or not it has no 
bearing on the proposal.

Short of that, my intention is not to convince you, because I agree that this 
proposal would harm you (even
though I believe it will help increase security for the Java ecosystem as a 
whole), and for that, I am truly 
sorry. My intention is to try to focus on productive avenues that might lessen 
that harm.

— Ron

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-21 Thread Dalibor Topic


On 21.05.2021 03:40, Peter Firmstone wrote:
If there are those of us who wanted to maintain a fork of Java 17, 
focused on security, we could backport new features after they've been 
reviewed for security.


Would we be welcomed to do that here?  Otherwise is it something we 
should do on GitHub?


Once a Project Lead resigns, or in the case of a repository in the JDK 
Updates Project, a repository lead maintainer resigns, someone 
sufficiently qualified to do so is welcome to step up and continue 
maintaining a release under the umbrella of the JDK Updates Project.


Please see http://openjdk.java.net/projects/jdk-updates/maintainers.html 
for details, and keep in mind that as any process, it's open to change 
through discussion on the jdk-updates-dev mailing list.


Ideas like differently focused repositories were discussed for JDK 11 in 
the past on that list, but the discussion was inconclusive, fwiw. It's 
worth keeping in mind that adequately maintaining an update release is 
by no means a trivial affair, and as such, there is usually little 
desire in the long run to balkanize the comparatively sparse community 
of OpenJDK update release maintainers across vastly different 
approaches, even if that may initially seem appealing for various reasons.


cheers,
dalibor topic


--
 Dalibor Topic
Consulting Product Manager
Phone: +494089091214 , Mobile: +491737185961
, Video: dalibor.to...@oracle.com


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRB 246209
Geschäftsführer: Ralf Herrmann

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries




On 21/05/2021 6:58 pm, Ron Pressler wrote:
These are just opinions, it's nice to have them, but they're not 
helping. I think you'll find usages of SecurityManager api's are far 
more widespread than your opinion suggests, but that's just my 
opinion too lol.
I guess you could say they’re my opinions because there is no 
conclusive proof, but they are based
on empirical data. At least you should scan GitHub and Maven Central. 
That few libraries are properly
instrumented is yet another piece of evidence. This isn’t conclusive, 
and that is why we’re discussing
this here in an attempt to collect more information, but we have done 
our homework.



Can you share this list please?   If I see anything missing I can add it 
for you.





Yes, I think we should keep it simple, and keep calling it the 
principle of least privilege, to avoid confusion, it's very 
beneficial for reducing the consequences of perimeter security 
failure, even if your experts think otherwise.

It is absolutely not the principle of least privilege,


So I'm restricting permissions granted to only those required to perform 
the intended tasks of the software,  restricted even to a subset of 
which that software is capable, and you say it is not the principle of 
least privilege?


Please refer this policy file: 
https://www.dropbox.com/s/0w1c140zts93cmw/defaultnonactvm-policy.txt?dl=0


It's even specific to the JVM used, vendor, version and installation path.


Notice how the attached grants permission to code and principal? That 
means the code without the Principal cannot attain that privilege, nor 
can the Principal use that permission without the specified code?


This means if an attacker breaches peripheral protection systems, such 
as authentication, they can not perform anything that requires 
permission outside of the granted scope?


I execute exactly the code paths I want executed, with the user role I 
want to perform that task, I grant only the permissions required to 
perform the intended task.


How is this absolutely not the principle of least privilege?


Java (the last remaining mainstream platform
with a mechanism that assigns permissions on a per-class basis).


Java Policy doesn't assign permissions on a per-class basis, it assigns 
them by ProtectionDomain, or by ClassLoader, or by CodeSource, or by 
Signer Certificates, or by Principal, or by a combination of Principal's 
and (ProtectionDomain or ClassLoader or CodeSource, or signer 
Certificates) and Certificates.  I don't really want to document all the 
possibilities here if yo don't mind.


How do you critique something if you don't understand how it works?

With test cases, I can generate policy files for the principle of least 
privilege for any Java software, including dependencies.


Not only that, but I do it without impacting performance or scalability.

Show me some evidence for your arguments, name your experts you speak of 
so often.


If you are going to argue, back it up with hard evidence, not nonsense.

I provide you with hard evidence, show me the same courtesy and respect 
please.


I'm not seeing any evidence that you have done much homework at all sir?

Previously you claimed SecurityManager didn't even work, that a 
Doctorate in Nuclear particle physics was required to use it.


I don't wish to publicly show that I doubt your credibility, but you are 
making it difficult for me not to sir.  It is your user base you need to 
convince, so far, you are not very convincing.



--
Respectfully,

Peter Firmstone

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 21 May 2021, at 04:55, Peter Firmstone  wrote:
> 
> 
> Yes everything is a compromise and there are trade-offs.   The way I see it, 
> the cheapest way to maintain security is to find others who share a common 
> pain point is to maintain a copy of OpenJDK  focused on security.   We can 
> audit upstream changes and add them later, with the security cost penalty, 
> without throwing out the huge amount of effort performed by JDK developers 
> over the years, there's no way we can re-implement it economically, so this 
> appears the most sensible option.
> 

That may be the way you see it, but I think you have to accept that many 
security experts don’t think
that focusing on the Security Manager and focusing on security are the same 
thing. We want to remove the 
SM *because* we want to focus on security measures that will have a larger 
impact in the real world. Even 
if you think that the SM is the best path to Java security you must accept that 
others do not, and that 
even if we’re misguided, we’re doing this because we believe it will help 
improve security, and that the 
SM harms it. So if you want to maintain the Security Manager in the JDK and 
ecosystem libraries, you can 
say so, but saying that that is “focusing on security” is a mischaracterisation 
because it depends on
assertions that you know are controversial at the very least.

> 
> These are just opinions, it's nice to have them, but they're not helping.   I 
> think you'll find usages of SecurityManager api's are far more widespread 
> than your opinion suggests, but that's just my opinion too lol.

I guess you could say they’re my opinions because there is no conclusive proof, 
but they are based
on empirical data. At least you should scan GitHub and Maven Central. That few 
libraries are properly 
instrumented is yet another piece of evidence. This isn’t conclusive, and that 
is why we’re discussing
this here in an attempt to collect more information, but we have done our 
homework.

> 
> Yes, I think we should keep it simple, and keep calling it the principle of 
> least privilege, to avoid confusion, it's very beneficial for reducing the 
> consequences of perimeter security failure, even if your experts think 
> otherwise.

It is absolutely not the principle of least privilege, which was formed long 
before the Security Manager
existed and is applied for all software, even that not written in Java (the 
last remaining mainstream platform 
with a mechanism that assigns permissions on a per-class basis). It is true 
that the SM allows smaller
units than the process or the user for the purpose of permissions, but if you 
think the principle means that
least privilege must be assigned at the smallest unit theoretically possible, 
then the Security Manager
doesn’t do that, and if you think it’s a matter of picking an effective unit 
granularity, then I believe
other measures apply it more effectively.

But there is something you keep missing here, and that is that the question of 
whether or not there are
circumstances in which the Security Manager will stop an attack — and there are 
— is irrelevant to the 
question of whether it is an effective security mechanism. That an elaborate 
trap will stop intruders who 
happen to try to enter my property at a specific spot doesn’t make it an 
effective mechanism, because a 
fence surrounding my property will stop even more intruders and do it more 
cheaply. “Beneficial” for us 
doesn’t mean “might help”, but what is the amount of total help offered per 
unit cost *compared to all 
other mechanisms’ benefit per cost*. In other words, we ask ourselves, is the 
Security Manager the best 
thing to invest in if we want security compared to all other things we can 
invest in?

If your codebase is trusted, then what you want to defend against are 
accidental vulnerabilities, 
i.e. bugs. Suppose your application requires permissions X and Y to run. What 
the Security Manager 
allows you is to notice that your application is made of two components, A and 
B, and after analysis 
conclude that while A requires permissions X and Y, B requires only X, and to 
grant only X to B. This 
can preemptively prevent exploits in your application that: 1. target component 
B and 2. require permission 
X. How much is preventing this particular scenario worth and are there ways to 
prevent more?

Just as the Security Manager doesn’t find it a good tradeoff to separate A and 
B at a method granularity, 
we don’t think it’s a good tradeoff to separate them at a class granularity. 
Grant your entire process 
permissions X and Y, and monitor it. Modern detection methods can automatically 
detect an unusual behaviour 
if B attempts Y and alert you to fix the bug, and we prefer investing the very 
high effort of maintaining
the SM at reducing the attack surface area of the JDK overall, reducing the 
chance of attacks on either A 
or B, whether they require permissions X or Y, and also being always on for 
everyone.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-20 Thread Peter Firmstone




On 18/05/2021 10:09 pm, Ron Pressler wrote:



On 18 May 2021, at 12:27, Peter Firmstone  wrote:


However I disagree that the Principle of least privilege is wrong headed, I 
think you've been discussing sandbox concepts with the experts and they're 
going to tell you that's a bad idea.  But the two aren't the same, one is 
access control, the other is attempted complete leak proof isolation,  which is 
a very difficult thing to do that grows exponentially with your API surface 
area, I'm sure in years to come crackers will find vulnerabilities in VM's too. 
Sandboxing would work if you removed most of the library code and features and 
limited memory and threads, but I don't think anyone is seriously considering 
that.  Java for applets should have been it's own stripped down limited JVM.

When you say the “principle of least privilege” you seem to imply that it is at 
*all* cost. Many believe that
the attempt to assign different privileges to different *pieces of code* (not 
different people) is not effective
from a cost/benefit perspective. In other words, the effort would have a bigger 
impact on security if directed
elsewhere. After all, the same principle would imply that we’d need to afford 
different permissions at a method
granularity rather than class granularity.



No, actually to date, it's been a very affordable option, probably 
because the burden has been on Openjdk developers to date, to which I'm 
very grateful.   It doesn't impact performance and it allows me to 
reduce the attack surface of my programs, especially in regard to 
dependencies.



https://debricked.com/blog/2021/01/02/vulnerabilities-in-dependencies/



What sort of cost, you mean development cost, the cost of understanding 
doPrivileged?

Both, but mostly the former.



Yes everything is a compromise and there are trade-offs.   The way I see 
it, the cheapest way to maintain security is to find others who share a 
common pain point is to maintain a copy of OpenJDK  focused on 
security.   We can audit upstream changes and add them later, with the 
security cost penalty, without throwing out the huge amount of effort 
performed by JDK developers over the years, there's no way we can 
re-implement it economically, so this appears the most sensible option.






At least to me, it's just a simple lambda expression, it's not difficult.  It 
think people are making this more complex than it needs to be due to a 
proliferation of Permissions, but even that I manage with tooling.

There’s no point to argue over this. It’s been tried for a couple of decades, 
people don’t want it, experts say it’s
not cost-effective, no popular platform after Java and .NET has chosen to 
invest in it, and .NET has dropped it already.
Even if you convinced me that the effort of attempting to afford different 
permissions to different code in the same
process was an effective use of resources, if you could have changed the habits 
of millions of developers you would
have done it by now. You can carry on the argument over whether this is a good 
or bad idea on security forums and at
security conferences, but that it didn’t pan out, adoption-wise, in practice is 
an empirical fact (that it's worked
great *for you* is completely irrelevant). Even good ideas can fail to gain 
traction, and we shouldn’t throw good money
after bad.



These are just opinions, it's nice to have them, but they're not 
helping.   I think you'll find usages of SecurityManager api's are far 
more widespread than your opinion suggests, but that's just my opinion 
too lol.


You've probably have never used it, so you don't really understand it, I 
can't argue with ignorance and you can't understand the benefit, if you 
are only asking others for their opinions, you are likely surrounded by 
people with the same opinion, so you're suffering from confirmation bias 
without any practical application, as is anyone else that doesn't use it.


https://berteig.com/coaching/confirmation-bias/





But it's such a shame to lose access control as collateral damage.

Most applications that do access control today do not use the Security Manager 
for that. When you say “access control”
you mean something very specific, which is not what others mean when they say 
access control. In particular, even doAs
is proposed to remain.


— Ron



Yes, I think we should keep it simple, and keep calling it the principle 
of least privilege, to avoid confusion, it's very beneficial for 
reducing the consequences of perimeter security failure, even if your 
experts think otherwise.


--
Regards,
 
Peter Firmstone

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-20 Thread Peter Firmstone

If there are those of us who wanted to maintain a fork of Java 17, 
focused on security, we could backport new features after they've been 
reviewed for security.


Would we be welcomed to do that here?  Otherwise is it something we 
should do on GitHub?


Cheers,

Peter.

On 21/05/2021 11:25 am, David Black wrote:

On Thu, 20 May 2021 at 21:27, Andrew Dinn  wrote:

On 18/05/2021 23:06, David Black wrote:

I don't think that this thinking is unique but it might not be worth
the "cost" to Oracle to maintain something that seemingly for various
reasons Oracle has little interest in maintaining (we're not in
applet-land anymore). I would like to encourage proposals that mean
that people who want to do 4, who implement further security hardening
where others seemingly shy away, can continue to do 4.

Please don't do that. The cost Ron is talking about is not to "Oracle".
It is a cost to the OpenJDK project as a whole.

Sorry about that, that is a good point.


Likewise, the lack of project team interest in maintaining the security
manager and self-evident interest in applying resources to providing
other, more valuable Java capabilities is not simply restricted to
"Oracle" project members.

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,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-20 Thread David Black

On Thu, 20 May 2021 at 21:27, Andrew Dinn  wrote:
>
> On 18/05/2021 23:06, David Black wrote:
> > I don't think that this thinking is unique but it might not be worth
> > the "cost" to Oracle to maintain something that seemingly for various
> > reasons Oracle has little interest in maintaining (we're not in
> > applet-land anymore). I would like to encourage proposals that mean
> > that people who want to do 4, who implement further security hardening
> > where others seemingly shy away, can continue to do 4.
> Please don't do that. The cost Ron is talking about is not to "Oracle".
> It is a cost to the OpenJDK project as a whole.

Sorry about that, that is a good point.

> Likewise, the lack of project team interest in maintaining the security
> manager and self-evident interest in applying resources to providing
> other, more valuable Java capabilities is not simply restricted to
> "Oracle" project members.
>
> 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
>


-- 
David Black / Security Engineer.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-20 Thread Andrew Dinn


On 18/05/2021 23:06, David Black wrote:

I don't think that this thinking is unique but it might not be worth
the "cost" to Oracle to maintain something that seemingly for various
reasons Oracle has little interest in maintaining (we're not in
applet-land anymore). I would like to encourage proposals that mean
that people who want to do 4, who implement further security hardening
where others seemingly shy away, can continue to do 4.
Please don't do that. The cost Ron is talking about is not to "Oracle". 
It is a cost to the OpenJDK project as a whole.


Likewise, the lack of project team interest in maintaining the security 
manager and self-evident interest in applying resources to providing 
other, more valuable Java capabilities is not simply restricted to 
"Oracle" project members.


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: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-20 Thread Peter Firmstone




On 18/05/2021 10:21 am, Ron Pressler wrote:

On 18 May 2021, at 01:11, Peter Firmstone  wrote:

Your ideas are great in theory, in practice, the problem with your Agent 
proposal is every JVM release needs to be reviewed, and we have to review 
Java's internal implementation code, and understand it in order to instrument 
it.

Absolutely. But that is exactly the work OpenJDK maintainers are required to do 
today to support something most
people want better alternatives for at the expense of those better alternatives 
and other work.



The Principle of Least Privilege reduces the consequences resulting from 
attacks that penetrate external security defenses, whether by social 
engineering, failure to sanitize input, protocols, or platform 
vulnerabilities.



After many years of pain, JDK development work has not been wasted, I 
for one am grateful for the development efforts and thoughts put into 
securing the JVM.   It is expensive and now your employer has decided 
they no longer wish to carry this expense, pushing it downstream.


Java has a proven and well tested security API, it's flaws are generally 
well understood.


At sometime in the future, Java's internal security defenses will be 
removed, and new code will no longer perform permission checks, so any 
breaches of external defenses will result in a JVM being Pwned.


After considering the proposals for new Security API, I have decided 
that the Java 1.8 to Java 1.17 versions will be the most suitable as it 
has the best well developed and understood security architecture, 
requiring little further development work.


The new proposals arising from this JEP present a significant 
development upgrade cost, and these new API's that we need to use for 
building new security architecture around, won't be battle hardened, are 
experimental and haven't passed the test of time.


My assessment is the cost to upgrade is too high and far too great a 
risk in this instance, the least cost and safest option is to stay with 
well proven, deployment tested, high performance, hardened existing API's.


I wish the OpenJDK project success in their future endeavors.  We will 
try to support later Java versions in Service implementations, similar 
to other languages, however these will not be able to consume other 
services.  This may enable users to take advantage of later language 
features.  However we will always require the use of Java 1.8 to 1.17 as 
service consumers.


I am grateful for the efforts, which appear to be thought of as wasted 
efforts or bad money, however this time spent addressing security 
issues, will leave the series of Java versions from 1.8 to 1.17 as some 
of the most secure versions of any software platform, as an asset of 
significant value to those who value security.


Thank you.

Peter Firmstone.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread David Black

On Tue, 18 May 2021 at 22:24, Ron Pressler  wrote:
>
>
> > On 18 May 2021, at 07:10, David Black  wrote:
> >
> >
> > I hope you aren't being rude on purpose by continuing to 1) top post
> > and 2) not ignore various parts of my emails.
> >
>
> This isn’t a debate forum. We’re trying to collect information, not
> to convince every last person. I respond to what I think I can comment
> on.

To be honest this still comes off as rude to me but at least you
aren't top posting and have explained why various things have been
left out.
Additionally, thank you for engaging with my emails. My point in
responding isn't to debate you but to ensure that a view is registered
& when it seems that things are left out it seems odd to me.

> >
> > I am not trying to be rude but I would like to ask what is more expensive -
> > 1) auditing 1,000,000 lines of code - with active development on going
> > 2) re-architecting an application so that the main process ?cannot?
> > make new connections after a certain point (preventing new FDs from
> > being opened) & making external connections from another process which
> > has operating/configuration/other restrictions on it to prevent it
> > from talking with sensitive network locations
> > 3) examining all known locations using a security manager in a
> > non-enforcing mode or as you noted - the Java Flight recorder & fixing
> > all known currently existing locations
> > 4) ^ 3 but you use a security manager or something that lets you make
> > decisions about connections/$things such that you can block in
> > addition to monitor things
>
>
> I happen to think that the most cost-effective thing would be to assign
> the entire trusted process the minimal permissions it requires, to monitor
> it for suspicious activity with JFR, and to invest the effort required to
> maintain the Security Manager in security measures that most people might
> actually use. Is that 3? The question of whether or not it’s worth it to go
> from 3 to 4 depends on the added cost vs the added benefit, compared to all
> other options. I happen to think it’s not worth it, but the relevant
> maintainers might well consider some inexpensive building blocks for those
> who think differently, and wish to construct a code-origin based permission
> system.

I don't think that this thinking is unique but it might not be worth
the "cost" to Oracle to maintain something that seemingly for various
reasons Oracle has little interest in maintaining (we're not in
applet-land anymore). I would like to encourage proposals that mean
that people who want to do 4, who implement further security hardening
where others seemingly shy away, can continue to do 4.


-- 
David Black / Security Engineer.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread Ron Pressler

> On 18 May 2021, at 07:10, David Black  wrote:
> 
> 
> I hope you aren't being rude on purpose by continuing to 1) top post
> and 2) not ignore various parts of my emails.
> 

This isn’t a debate forum. We’re trying to collect information, not 
to convince every last person. I respond to what I think I can comment 
on.

> 
> I am not trying to be rude but I would like to ask what is more expensive -
> 1) auditing 1,000,000 lines of code - with active development on going
> 2) re-architecting an application so that the main process ?cannot?
> make new connections after a certain point (preventing new FDs from
> being opened) & making external connections from another process which
> has operating/configuration/other restrictions on it to prevent it
> from talking with sensitive network locations
> 3) examining all known locations using a security manager in a
> non-enforcing mode or as you noted - the Java Flight recorder & fixing
> all known currently existing locations
> 4) ^ 3 but you use a security manager or something that lets you make
> decisions about connections/$things such that you can block in
> addition to monitor things

I happen to think that the most cost-effective thing would be to assign
the entire trusted process the minimal permissions it requires, to monitor 
it for suspicious activity with JFR, and to invest the effort required to
maintain the Security Manager in security measures that most people might
actually use. Is that 3? The question of whether or not it’s worth it to go
from 3 to 4 depends on the added cost vs the added benefit, compared to all
other options. I happen to think it’s not worth it, but the relevant 
maintainers might well consider some inexpensive building blocks for those 
who think differently, and wish to construct a code-origin based permission 
system.

— Ron

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread Ron Pressler

> On 18 May 2021, at 12:27, Peter Firmstone  wrote:
> 
> 
> However I disagree that the Principle of least privilege is wrong headed, I 
> think you've been discussing sandbox concepts with the experts and they're 
> going to tell you that's a bad idea.  But the two aren't the same, one is 
> access control, the other is attempted complete leak proof isolation,  which 
> is a very difficult thing to do that grows exponentially with your API 
> surface area, I'm sure in years to come crackers will find vulnerabilities in 
> VM's too. Sandboxing would work if you removed most of the library code and 
> features and limited memory and threads, but I don't think anyone is 
> seriously considering that.  Java for applets should have been it's own 
> stripped down limited JVM.

When you say the “principle of least privilege” you seem to imply that it is at 
*all* cost. Many believe that
the attempt to assign different privileges to different *pieces of code* (not 
different people) is not effective
from a cost/benefit perspective. In other words, the effort would have a bigger 
impact on security if directed
elsewhere. After all, the same principle would imply that we’d need to afford 
different permissions at a method
granularity rather than class granularity.

> 
> What sort of cost, you mean development cost, the cost of understanding 
> doPrivileged?

Both, but mostly the former.

> 
> At least to me, it's just a simple lambda expression, it's not difficult.  It 
> think people are making this more complex than it needs to be due to a 
> proliferation of Permissions, but even that I manage with tooling.

There’s no point to argue over this. It’s been tried for a couple of decades, 
people don’t want it, experts say it’s 
not cost-effective, no popular platform after Java and .NET has chosen to 
invest in it, and .NET has dropped it already.
Even if you convinced me that the effort of attempting to afford different 
permissions to different code in the same 
process was an effective use of resources, if you could have changed the habits 
of millions of developers you would 
have done it by now. You can carry on the argument over whether this is a good 
or bad idea on security forums and at 
security conferences, but that it didn’t pan out, adoption-wise, in practice is 
an empirical fact (that it's worked 
great *for you* is completely irrelevant). Even good ideas can fail to gain 
traction, and we shouldn’t throw good money 
after bad.

> 
> But it's such a shame to lose access control as collateral damage.

Most applications that do access control today do not use the Security Manager 
for that. When you say “access control” 
you mean something very specific, which is not what others mean when they say 
access control. In particular, even doAs 
is proposed to remain.

— Ron

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread Peter Firmstone




On 18/05/2021 8:49 pm, Ron Pressler wrote:



On 18 May 2021, at 03:39, Peter Firmstone  wrote:


Is it also possible to consider directing file access and network access 
through single points of access?   This will simplify the process so we don't 
need to scour the entire codebase for usages.


Of all your suggestions, I think this is the one that will be seriously 
considered from a cost/benefit
perspective, although probably not as part of this JEP.



Thank you ,appreciated.





What about doPrivileged calls?   Will they remain in existing Java library 
code, so we can utilise them?  To avoid viral permission propagation?

Doubtful. That is where much of the cost is, and it would mean investing 
significant resources into supporting
a use-case that what seems like the vast majority of security experts think is 
a wrong-headed approach, for the sake
of the few who disagree. Even as an additional mechanism that might, maybe, 
block exploiting some vulnerability as a
result of some particular bug in some cases, sometimes, maybe, the high cost 
doesn’t justify what we believe is the
extra defence gained compared to the gain of such an effort directed elsewhere.

— Ron


Oh well, there was no harm in asking.

I agree that sandboxing is the wrong approach, it's unfortunate that 
this wasn't seen as a potential issue in the early days. It's similar 
with Java Serialization, if they tried to do less initially it would 
have been much better, but they pushed to envelope too far.


But I'm pretty sure we've moved on from discussing sandboxes, no one is 
claiming that as their use case.


However I disagree that the Principle of least privilege is wrong 
headed, I think you've been discussing sandbox concepts with the experts 
and they're going to tell you that's a bad idea.  But the two aren't the 
same, one is access control, the other is attempted complete leak proof 
isolation,  which is a very difficult thing to do that grows 
exponentially with your API surface area, I'm sure in years to come 
crackers will find vulnerabilities in VM's too. Sandboxing would work if 
you removed most of the library code and features and limited memory and 
threads, but I don't think anyone is seriously considering that.  Java 
for applets should have been it's own stripped down limited JVM.


Our problem is we will need to grant remote third party's AllPermission 
because they are not represented as a Subject based ProtectionDomain in 
the JVM, but then we could implement some sort of analysis that removes 
their ability to connect at all if they violate policy.


But this doesn't seem very workable.  Thankfully we have a very good, 
functional and highly scalable solution available now.


What sort of cost, you mean development cost, the cost of understanding 
doPrivileged?


At least to me, it's just a simple lambda expression, it's not 
difficult.  It think people are making this more complex than it needs 
to be due to a proliferation of Permissions, but even that I manage with 
tooling.


AccessController.doPrivileged uses 1.3% of CPU time in my system, and 
I'm sure I use it far more than many, so I don't think your talking 
about performance.


Thankfully access control is much simpler today than say programming 
concurrently, but I try to do both well.   I truly don't find it 
difficult to use, but then I've built a bunch of tools that make it useable.


But I get that JVM developers have suffered a lot of pain with Security 
vulnerabilities due to Java Serialization and the Sandbox and just the 
mention of SecurityManager is received negatively.


But it's such a shame to lose access control as collateral damage.

Thanks again for spending the time to discuss.

--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread Ron Pressler

> On 18 May 2021, at 03:39, Peter Firmstone  wrote:
> 
> 
> Is it also possible to consider directing file access and network access 
> through single points of access?   This will simplify the process so we don't 
> need to scour the entire codebase for usages.
> 

Of all your suggestions, I think this is the one that will be seriously 
considered from a cost/benefit
perspective, although probably not as part of this JEP.

> What about doPrivileged calls?   Will they remain in existing Java library 
> code, so we can utilise them?  To avoid viral permission propagation?

Doubtful. That is where much of the cost is, and it would mean investing 
significant resources into supporting
a use-case that what seems like the vast majority of security experts think is 
a wrong-headed approach, for the sake 
of the few who disagree. Even as an additional mechanism that might, maybe, 
block exploiting some vulnerability as a 
result of some particular bug in some cases, sometimes, maybe, the high cost 
doesn’t justify what we believe is the 
extra defence gained compared to the gain of such an effort directed elsewhere.

— Ron

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread Peter Firmstone


Because people have been treating it like a sandbox.

Since it will take a number of years, can we at least consider my 
proposal and give it a try?  It may reduce the burden in the interim.


So this step deprecates it for removal, can we create a JEP for 
replacing the SecurityManager with AccessAssistant while retaining 
AccessController and AccessControlContext?


It's also true that Permisssion's are more numerous than necessary, 
because it has been treated like a sandbox.


If we rename and treat it like access control instead, we can reduce the 
burden, simplify permissions, provide tooling and make it much better 
than it is today.


We've been doing exactly that for years, and we knew the Java PolicyFile 
code was bad, but we never realised that JDK developers saw it in this 
light.


If I had realised that , I would have stepped in years ago to fix it. 
Maybe we got complacent because nothing was ever removed from Java for a 
very long time.


We've been using it silently and efficiently for years.

Regards,

Peter.


On 18/05/2021 7:13 pm, Alan Bateman wrote:



On 18/05/2021 08:36, Peter Firmstone wrote:

:

It's a perception issue, I understand, but we can fix that far less 
painfully.


With respect, I don't see a viable route here. SM/AccessController and 
most of that security architecture has been an albatross around our 
necks for years. This JEP is the first step in pulling the JDK out of 
the sandboxing and policy enforcement business. It will take several 
releases and years to get there. Yes, it will be painful for those 
that have embraced this architecture but there will be years of 
supported releases to plan or develop alternatives. There is a wider 
group that have been using the SM as a means to intercept network, 
file and several other operations. This is an area that might need to 
be exploded further to see if an alternative solution is imported for 
the JDK to provider. We don't think that this needs to be fully 
explored and decided on before making progress on the deprecation.


-Alan


--
Regards,
 
Peter Firmstone

0498 286 363
Zeus Project Services Pty Ltd.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread Alan Bateman





On 18/05/2021 08:36, Peter Firmstone wrote:

:

It's a perception issue, I understand, but we can fix that far less 
painfully.


With respect, I don't see a viable route here. SM/AccessController and 
most of that security architecture has been an albatross around our 
necks for years. This JEP is the first step in pulling the JDK out of 
the sandboxing and policy enforcement business. It will take several 
releases and years to get there. Yes, it will be painful for those that 
have embraced this architecture but there will be years of supported 
releases to plan or develop alternatives. There is a wider group that 
have been using the SM as a means to intercept network, file and several 
other operations. This is an area that might need to be exploded further 
to see if an alternative solution is imported for the JDK to provider. 
We don't think that this needs to be fully explored and decided on 
before making progress on the deprecation.


-Alan

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread Peter Firmstone




On 18/05/2021 4:10 pm, Alan Bateman wrote:

On 18/05/2021 03:39, Peter Firmstone wrote:

:


Yes, I realize that, it is my understanding that because this is a 
security concern, it is not something the community is allowed to 
provide support for at OpenJDK, hence my suggestion to Alan, to make 
it possible for this to happen by changing the security level and 
calling it an access control layer concern.


Sorry, I was too busy and didn't have time to reply to your previous 
mail on this and the performance anomaly in Java 14.


I'm dubious about your suggestion. Every issue or report that Java has 
a security bug has to be analyzed on the assumption that it may be a 
vulnerability. Saying that SM bypass or a ninja move that disables the 
SM is not a security concern would create a perception issue. It would 
get lost in the discussion that the SM is rarely used in the way that 
it was envisaged 20+ years ago. The other thing is that it wouldn't 
remove the ongoing burden to insert/audit permission checks, check 
that ACC are captured and used in the right places, and of course 
testing as it's another execution mode.


-Alan.



Thanks Alan,

It's a perception issue, I understand, but we can fix that far less 
painfully.


You could create a new parent class of SecurityManager that's more aptly 
named, for example AccessAssistant, and deprecate SecurityManager for 
removal.


That's actually pretty easy, even backport the new class to earlier 
versions of Java, so libraries can eliminate usages of SecurityManager 
sooner.


This would give us time to change our dependencies to the superclass, 
and it eliminates the name perception issue.


"AccessAssistant, is only intended to assist with access control 
measures to implement the principle of least privilege, while it may 
reduce the impact of a security breach, it's not capable of preventing 
it, therefore bugs in access decisions aren't given the same attention 
as security bugs, as both users and code are trusted."


AccessController and AccessControlContext have functionality that we 
depend on for access control and to obtain user credentials for 
authentication.


Let the community manage it as an access control layer, when we find the 
ACC has forgotten to be captured, we can fix it.   When someone forgets 
to capture the ACC, the thread cannot establish a secure connection, it 
will get noticed and fixed, it alone cannot cause a security breach.


We use TLS connections, sanitize data, atomic failure, input validation 
and authentication for security, we only use access controls and Policy 
for limiting access of trusted users and code and to obtain user 
credentials.   Access control and POLP gets those boxes ticked and might 
be the difference for choosing Java over another platform.


If people aren't defensively parsing their input, not using secure 
connections and authentication and someone takes advantage of that, well 
it's just too bad, it's their fault.


If someone is using trusted connections but there's a successful 
phishing attack on user credentials, then the attacker can usually only 
obtain what the user has access to, yes it is possible to perform a 
privilege escalation attack, but the point is the breach has already 
occurred, the security vulnerability is not access controls, it was the 
authentication system failure.


Don't stress the performance anomaly, it hasn't regressed in later 
versions and the standard Java Policy provider will mask it.   You'll 
only notice it when using a scalable policy provider.  If I see it again 
in any long term releases, I'll let you know.   I suspect whatever 
caused the problem was spotted and fixed already.


--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread David Black

Hi,

On Tue, 18 May 2021 at 10:13, Ron Pressler  wrote:
>
> We can call any mechanism that might impose restrictions a mitigation, but 
> that
> doesn’t mean that any mechanism is worth its cost. I believe that the evidence
> gathered over the past few decades shows that attempting to assign different
> permissions to code of different origin in the same process is not a 
> particularly
> effective way of increasing security compared to the alternatives, which is 
> why
> the only other mainstream platform to employ such a mechanism other than Java 
> has
> dropped it some years ago, and no other such platform has adopted it since.

I hope you aren't being rude on purpose by continuing to 1) top post
and 2) not ignore various parts of my emails.
To be clear, what I have written is partially answered by some of your
other emails which you talk about using a java agent and or hooks
which I mentioned in my previous email (& to say it again ... hooks
seem like they would be similar to a security manager).

> I don’t think rearchitecting is required. What’s required is a reexamination 
> of
> security-per-hour-effort gained by trying to assign different permissions to
> different code sources.

I am not trying to be rude but I would like to ask what is more expensive -
1) auditing 1,000,000 lines of code - with active development on going
2) re-architecting an application so that the main process ?cannot?
make new connections after a certain point (preventing new FDs from
being opened) & making external connections from another process which
has operating/configuration/other restrictions on it to prevent it
from talking with sensitive network locations
3) examining all known locations using a security manager in a
non-enforcing mode or as you noted - the Java Flight recorder & fixing
all known currently existing locations
4) ^ 3 but you use a security manager or something that lets you make
decisions about connections/$things such that you can block in
addition to monitor things

Let's say you want to do 1 - you likely will not be able to keep up
with active development regardless of cost and humans make mistakes.
Let's say you want to do 2 - we are talking about re-architecting a
sizable application - it might not be possible to shift to your
suggested split model and it also imposes a relatively high barrier to
entry/additional complexity (e.g. additional monitoring) as well.
Let's say you want to do 3 - this works but it doesn't do anything to
help with changes to code changes, libraries, and java itself.
Let's say you want to do 4 - this works but it won't be 100% secure,
what if the class you permit somehow ends up in all call stacks/at the
"allowed" location, we get the benefits of 3 but with some additional
protection.

Real world software security experience -^ will likely push security
engineers towards 4 depending upon performance impacts etc.

If we end up with hooks in places which allow us to make decisions but
don't try to protect against tearing down/removing a "security
manager" & the hooks are easier to use than the existing security
manager, that sounds workable to me (not desirable but workable). (I
could go on and rant about about how oracle made changes that mean
that if you try to use a custom security manager in java 11 without
referencing internal java classes you have a performance penalty - or
how there are security related applet & other hangovers that hinder
the use of the security manager in java applications).

>
> > On 18 May 2021, at 01:02, David Black  wrote:
> >
> > Hi Ron,
> >
> > On Mon, 17 May 2021 at 21:38, Ron Pressler  wrote:
> >>
> >> I would say that trying to mitigate attacks on vulnerabilities in trusted 
> >> code based on specific code paths is
> >> not recommended. You’re trying to preemptively defend agains something 
> >> complex — a security bug — with
> >> another complex mechanism. Even if you do happen to defend against a 
> >> particular attack attempt due to a bug
> >> that happens to be in the “less trusted” code rather than in the more 
> >> trusted code, the cost/benefit to this
> >> approach is not very attractive, in my opinion.
> >
> > That is your opinion and I will note that your reply didn't reference
> > my references that noted that there are & have been bugs in libraries
> > and java itself which make mitigating SSRF attacks difficult.
> > With regards to mitigating SSRF "something complex", I'd argue that it
> > isn't complex in itself but mitigating SSRF can be, with another
> > complex mechanism - I will note that implementing the mechanism is
> > rather simple so long as you are not using the built in java security
> > manager.
> >
> >> I think it is easier and simpler (and so more secure) to not differentiate 
> >> codepaths in the same process, grant
> >> whatever minimal privileges are required to the entire process with more 
> >> watertight mechanisms than the SM,
> >> and then actively monitor it — say, with streaming JFR events,

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-18 Thread Alan Bateman


On 18/05/2021 03:39, Peter Firmstone wrote:

:


Yes, I realize that, it is my understanding that because this is a 
security concern, it is not something the community is allowed to 
provide support for at OpenJDK, hence my suggestion to Alan, to make 
it possible for this to happen by changing the security level and 
calling it an access control layer concern.


Sorry, I was too busy and didn't have time to reply to your previous 
mail on this and the performance anomaly in Java 14.


I'm dubious about your suggestion. Every issue or report that Java has a 
security bug has to be analyzed on the assumption that it may be a 
vulnerability. Saying that SM bypass or a ninja move that disables the 
SM is not a security concern would create a perception issue. It would 
get lost in the discussion that the SM is rarely used in the way that it 
was envisaged 20+ years ago. The other thing is that it wouldn't remove 
the ongoing burden to insert/audit permission checks, check that ACC are 
captured and used in the right places, and of course testing as it's 
another execution mode.


-Alan.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries




On 18/05/2021 10:21 am, Ron Pressler wrote:



On 18 May 2021, at 01:11, Peter Firmstone  wrote:

Your ideas are great in theory, in practice, the problem with your Agent 
proposal is every JVM release needs to be reviewed, and we have to review 
Java's internal implementation code, and understand it in order to instrument 
it.

Absolutely. But that is exactly the work OpenJDK maintainers are required to do 
today to support something most
people want better alternatives for at the expense of those better alternatives 
and other work.



Yes, I realize that, it is my understanding that because this is a 
security concern, it is not something the community is allowed to 
provide support for at OpenJDK, hence my suggestion to Alan, to make it 
possible for this to happen by changing the security level and calling 
it an access control layer concern.


Also is OpenJDK using static analysis to spot bugs?  Just out of 
curiosity, it's something we do for our code.


POLP isn't perfect, I acknowledge that, but it's much better than 
nothing as it does assist to limit damage in the event of an attack.  If 
this is the only issue, I'm sure the community will be willing to 
assist.   It would be less work for me to maintain the existing 
implementation than try to re-implement this functionality in a 
relatively compatible way.   I would review OpenJDK's permissions as 
well, given that I use doPrivileged and POLP regularly, it's probably 
going to be more obvious to me where bugs are,  I do see evidence of 
these bugs in my policy file generation, so I would be able to fix a 
number relatively quickly.


Unfortunately for us to put these proxy's into separate processes, in 
order to use OS level access control, we could have hundreds to 
thousands of processes running.  So it's not really an option.  We would 
still need to communicate with that process, so it's starting to make it 
difficult to manage secure connections etc.


ClassLoader's are so lightweight in comparison to a process.

Our RFC 3986 and RFC 5952 URI based ClassLoader is also so much faster 
than URLClassLoader, so it's not just security performance, I looked for 
hotspots and eliminated all of them.   Where OpenJDK is doing dns 
network calls, we normalize ASCII strings.  It's AL2.0 licensed code 
refactored from Harmony, so I don't think it's an option for OpenJDK.


We'd like to avoid performance penalties as well, other options proposed 
have unknown performance costs, which may be significantly worse than 
current performant and scalable code. Remember our performance 
limitations are JVM native sockets, if you look at our hotspots, they're 
all JVM native methods.


While I admit that what we do with distributed software isn't commonly 
done in modern software, as most gave it up as too difficult years ago, 
we persisted and solved some very difficult problems.






Maybe if you put hooks (annotations?) into the JVM code, so it was easier for 
agents to know which calls need to be controlled for access decisions?   But 
then if not many people are using it, it will suffer neglect.

Yeah, it sounds neither here nor there, but the relevant maintainers will 
consider it.



It may be the deciding factor for us, so I'd appreciate it if this can 
be considered.


Is it also possible to consider directing file access and network access 
through single points of access?   This will simplify the process so we 
don't need to scour the entire codebase for usages.


What about doPrivileged calls?   Will they remain in existing Java 
library code, so we can utilise them?  To avoid viral permission 
propagation?






It's your existing userbase with over 50% still using Java 8 that need 
convincing, who will be ultimate judge of the success or failure of this 
decision.

If you have data that contradicts our estimate of Security Manager usage among 
Java 8 users, please present it.

- Ron



I don't know what data you have, it's not something I've considered 
polling, if I find anything, I will most certainly share it.



--
Regards,
 
Peter Firmstone

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 18 May 2021, at 01:11, Peter Firmstone  wrote:
> 
> Your ideas are great in theory, in practice, the problem with your Agent 
> proposal is every JVM release needs to be reviewed, and we have to review 
> Java's internal implementation code, and understand it in order to instrument 
> it.  

Absolutely. But that is exactly the work OpenJDK maintainers are required to do 
today to support something most 
people want better alternatives for at the expense of those better alternatives 
and other work.

> 
> Maybe if you put hooks (annotations?) into the JVM code, so it was easier for 
> agents to know which calls need to be controlled for access decisions?   But 
> then if not many people are using it, it will suffer neglect.

Yeah, it sounds neither here nor there, but the relevant maintainers will 
consider it.

> 
> It's your existing userbase with over 50% still using Java 8 that need 
> convincing, who will be ultimate judge of the success or failure of this 
> decision.

If you have data that contradicts our estimate of Security Manager usage among 
Java 8 users, please present it.

- Ron

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

We can call any mechanism that might impose restrictions a mitigation, but that
doesn’t mean that any mechanism is worth its cost. I believe that the evidence
gathered over the past few decades shows that attempting to assign different 
permissions to code of different origin in the same process is not a 
particularly
effective way of increasing security compared to the alternatives, which is why
the only other mainstream platform to employ such a mechanism other than Java 
has
dropped it some years ago, and no other such platform has adopted it since.

I don’t think rearchitecting is required. What’s required is a reexamination of 
security-per-hour-effort gained by trying to assign different permissions to 
different code sources.

— Ron

> On 18 May 2021, at 01:02, David Black  wrote:
> 
> Hi Ron,
> 
> On Mon, 17 May 2021 at 21:38, Ron Pressler  wrote:
>> 
>> I would say that trying to mitigate attacks on vulnerabilities in trusted 
>> code based on specific code paths is
>> not recommended. You’re trying to preemptively defend agains something 
>> complex — a security bug — with
>> another complex mechanism. Even if you do happen to defend against a 
>> particular attack attempt due to a bug
>> that happens to be in the “less trusted” code rather than in the more 
>> trusted code, the cost/benefit to this
>> approach is not very attractive, in my opinion.
> 
> That is your opinion and I will note that your reply didn't reference
> my references that noted that there are & have been bugs in libraries
> and java itself which make mitigating SSRF attacks difficult.
> With regards to mitigating SSRF "something complex", I'd argue that it
> isn't complex in itself but mitigating SSRF can be, with another
> complex mechanism - I will note that implementing the mechanism is
> rather simple so long as you are not using the built in java security
> manager.
> 
>> I think it is easier and simpler (and so more secure) to not differentiate 
>> codepaths in the same process, grant
>> whatever minimal privileges are required to the entire process with more 
>> watertight mechanisms than the SM,
>> and then actively monitor it — say, with streaming JFR events, which will be 
>> made richer, and already do
>> expose the stack trace — for suspicious activity. If a bug is found — fix it.
> 
> I am not familiar with the Java Flight recorder but the documentation
> for it seems to suggest that it is only for diagnostic purposes.
> 
>> 
>> If your application clearly has more trusted/less exposed components and 
>> less trusted/less exposed ones,
>> and you feel that they must be separated for security reasons, consider 
>> running them in different processes.
>> Process isolation is a more secure, better studied, and better supported 
>> security mechanism than the Security Manager.
> 
> My reading of your proposed solution is that it requires
> re-architecting applications to ensure that any potential security
> issues occur inside of an isolated and monitored component/process.
> However, we do not get to pick where security issues can develop. It
> is true we can mitigate the risk of security issues by using isolated
> processes but I think you may have missed my main point which is
> effectively "something that lets us examine $X, e.g. a network
> connection, before the action is performed let's us at least partially
> mitigate security vulnerabilities and while it might be ideal to have
> software that contains 0 security vulnerabilities in it that often
> isn't realistic." From my prior email - "So having a "belt and
> braces", prox(y|ies) and a security manager, approach is valuable."
> Perhaps a different but I would argue more complex solution would be
> to use a java agent to rewrite java classes so as to be able to
> implement class based checks at run time or to have java provide event
> hooks where decisions can be made (but ... that sounds rather similar
> to the current situation with the security manager).
> 
> I would like to apologise for the system we use at my place of work
> messing with the email subject. But I would appreciate it if you
> didn't top post to reply to my email as you have left out some
> concerns such as that Java 8 seemingly is still affected by
> https://bugs.openjdk.java.net/browse/JDK-8161016.
> 
> 
>> — Ron
>> 
>>> On 17 May 2021, at 03:11, David Black  wrote:
>>> 
>>> Hi Ron
>>> 
>>> On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
 
 
 
> On 13 May 2021, at 03:11, David Black  wrote:
> 
> 
> This seems somewhat more useful than 1 & 2 but imho it would be better to 
> be able to perform checks/grant access on a call stack basis.
 
 This is an important point we’re trying to get across. The very reason the 
 Security Manager was made this
 way is because it does *seem* better; certainly it is much more flexible. 
 However, twenty five years of
 experience have shown us that *in practice* this is not the case,

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to
review Java's internal implementation code, and understand it in order
to instrument it. But I do appreciate you took the time to do your
homework to make the suggestion.

Maybe if you put hooks (annotations?) into the JVM code, so it was
easier for agents to know which calls need to be controlled for access
decisions? But then if not many people are using it, it will suffer
neglect.

To answer your use case question below, we use a ClassLoader and
ProtectionDomain, to represent the remote server Subject, this is not
for authentication, just for access control. JAAS is used for
authentication of TLS endpoints. For services, the calling Subject is
run in the context of the thread on the remote machine for access
decisions also.

It's your existing userbase with over 50% still using Java 8 that need
convincing, who will be ultimate judge of the success or failure of this
decision.

Thanks for your time.

--
Regards,

Peter Firmstone

On 18/05/2021 8:16 am, Ron Pressler wrote:

On 17 May 2021, at 21:46, Peter Firmstone wrote:

Yes, you are talking about those who maintain and develop OpenJDK, but this is
only a small proportion of the overall Java developer ecosystem.

Not at all. I’m talking about the millions of developers who don’t get what
they need sooner because the
OpenJDK’s resources are invested in maintaining components that add little
value to the ecosystem.

No, it's not practical, but there's no viable upgrade path, so our only option
is indefinite maintenance of Java 17.

I’m not going to tell you where to put your money, but writing a Java agent is
orders of magnitude cheaper
than maintaining an eight-million-line codebase indefinitely.

In a distributed system that uses POJO's and Remote Method Invocation, a proxy
is used to invoke methods on an object in a remote JVM or any other language
for that matter, operating in another node or process. The proxy
implementation is not known, nor necessarily are it's communication methods
until runtime. It is loaded dynamically.

The proxy is trusted code (each implementation has different bytecode), but we
wish to run it with principles of least privilege, rather than an anything goes
approach.

https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEEqMlozJA$

I’m not sure I understand. If you’re not talking about a JDK mechanism, you can
change that mechanism
to not use the Security Manager, just as JAAS will be changed.

If the application needs access control, but the Java platform doesn't provide
it, and you must remove it for the application to run, then yes, the software
will be less secure as a result. This shouldn't be difficult to understand.

I understand but disagree.

No, but it is a useful security layer to control access.

The utility of *this particular mechanism* does not justify the cost of
maintaining it.
The question isn’t if such a mechanism could be useful or not, but is this the
best use of resources to improve security?
In other words, the choice isn’t between this and nothing, but between this and
everything else.

It is not possible to implement fine grained access control in Java, or as a
library, this feature is low level JVM code.

Again, when you say fine-grained level access control you don’t mean
fine-grained level access control but the
particular features provided by the Security Manager; and those features — at
least those you sound most interested
in — are not low-level JVM code, and can be implemented in Java with a Java
agent, at least as an additional, albeit
imperfect layer of security, if you think this is a worthwhile and
cost-effective approach.

Developers who wish to develop new applications that require access control
should do so using another platform, those who have existing software
deployments, need to stay on Java 17 for example, indefinitely until EOL.

I strongly disagree; the Security Manager is not the only — and I would say
it’s not even the best — way to
offer access control. This JEP proposes removing Security Manager. That that
implies giving up on access control
is entirely your insistence on identifying the two. And if the only way you can
think of implementing access
control is with a call-stack code-sourcing mechanism, then I’m afraid other
platforms are not going to offer it,
because they also don’t share the view that this is the best, let alone the
only, way to do this.

New developments that require access control might consider the Microsoft CLR
for example, however I'm no expert, there may be better alternatives.

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-17 Thread David Black

Hi Ron,

On Mon, 17 May 2021 at 21:38, Ron Pressler  wrote:
>
> I would say that trying to mitigate attacks on vulnerabilities in trusted 
> code based on specific code paths is
> not recommended. You’re trying to preemptively defend agains something 
> complex — a security bug — with
> another complex mechanism. Even if you do happen to defend against a 
> particular attack attempt due to a bug
> that happens to be in the “less trusted” code rather than in the more trusted 
> code, the cost/benefit to this
> approach is not very attractive, in my opinion.

That is your opinion and I will note that your reply didn't reference
my references that noted that there are & have been bugs in libraries
and java itself which make mitigating SSRF attacks difficult.
With regards to mitigating SSRF "something complex", I'd argue that it
isn't complex in itself but mitigating SSRF can be, with another
complex mechanism - I will note that implementing the mechanism is
rather simple so long as you are not using the built in java security
manager.

> I think it is easier and simpler (and so more secure) to not differentiate 
> codepaths in the same process, grant
> whatever minimal privileges are required to the entire process with more 
> watertight mechanisms than the SM,
> and then actively monitor it — say, with streaming JFR events, which will be 
> made richer, and already do
> expose the stack trace — for suspicious activity. If a bug is found — fix it.

I am not familiar with the Java Flight recorder but the documentation
for it seems to suggest that it is only for diagnostic purposes.

>
> If your application clearly has more trusted/less exposed components and less 
> trusted/less exposed ones,
> and you feel that they must be separated for security reasons, consider 
> running them in different processes.
> Process isolation is a more secure, better studied, and better supported 
> security mechanism than the Security Manager.

My reading of your proposed solution is that it requires
re-architecting applications to ensure that any potential security
issues occur inside of an isolated and monitored component/process.
However, we do not get to pick where security issues can develop. It
is true we can mitigate the risk of security issues by using isolated
processes but I think you may have missed my main point which is
effectively "something that lets us examine $X, e.g. a network
connection, before the action is performed let's us at least partially
mitigate security vulnerabilities and while it might be ideal to have
software that contains 0 security vulnerabilities in it that often
isn't realistic." From my prior email - "So having a "belt and
braces", prox(y|ies) and a security manager, approach is valuable."
Perhaps a different but I would argue more complex solution would be
to use a java agent to rewrite java classes so as to be able to
implement class based checks at run time or to have java provide event
hooks where decisions can be made (but ... that sounds rather similar
to the current situation with the security manager).

I would like to apologise for the system we use at my place of work
messing with the email subject. But I would appreciate it if you
didn't top post to reply to my email as you have left out some
concerns such as that Java 8 seemingly is still affected by
https://bugs.openjdk.java.net/browse/JDK-8161016.

> — Ron
>
> > On 17 May 2021, at 03:11, David Black  wrote:
> >
> > Hi Ron
> >
> > On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
> >>
> >>
> >>
> >>> On 13 May 2021, at 03:11, David Black  wrote:
> >>>
> >>>
> >>> This seems somewhat more useful than 1 & 2 but imho it would be better to 
> >>> be able to perform checks/grant access on a call stack basis.
> >>
> >> This is an important point we’re trying to get across. The very reason the 
> >> Security Manager was made this
> >> way is because it does *seem* better; certainly it is much more flexible. 
> >> However, twenty five years of
> >> experience have shown us that *in practice* this is not the case, 
> >> certainly not when you look at the
> >> ecosystem as a whole. It is hard to get right, which results in people not 
> >> using the mechanism (which
> >> significantly reduces its utility and the value in maintaining it), or 
> >> worse, use it and think it gets
> >> the job done, but actually use it incorrectly, providing the illusion of 
> >> security without actual security.
> >
> > Agreed, but if you don't have this level of introspection/detail how
> > do you propose to, at least partially, mitigating bug classes such as
> > SSRF?
> >
> >>> Atlassian currently makes use of a security manager to prevent access to 
> >>> cloud metadata services that do not have an amazon sdk related class on 
> >>> the call stack. This helps to mitigate the impact of SSRF in applications 
> >>> running in a cloud environment 
> >>>

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 17 May 2021, at 21:46, Peter Firmstone  wrote:
> 
> 
> Yes, you are talking about those who maintain and develop OpenJDK, but this 
> is only a small proportion of the overall Java developer ecosystem.   

Not at all. I’m talking about the millions of developers who don’t get what 
they need sooner because the
OpenJDK’s resources are invested in maintaining components that add little 
value to the ecosystem.

> 
> No, it's not practical, but there's no viable upgrade path, so our only 
> option is indefinite maintenance of Java 17.

I’m not going to tell you where to put your money, but writing a Java agent is 
orders of magnitude cheaper
than maintaining an eight-million-line codebase indefinitely.

> 
> In a distributed system that uses POJO's and Remote Method Invocation, a 
> proxy is used to invoke methods on an object in a remote JVM or any other 
> language for that matter, operating in another node or process.   The proxy 
> implementation is not known, nor necessarily are it's communication methods 
> until runtime.  It is loaded dynamically.
> 
> The proxy is trusted code (each implementation has different bytecode), but 
> we wish to run it with principles of least privilege, rather than an anything 
> goes approach.
> 
> https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEEqMlozJA$
>  

I’m not sure I understand. If you’re not talking about a JDK mechanism, you can 
change that mechanism
to not use the Security Manager, just as JAAS will be changed.

> 
> If the application needs access control, but the Java platform doesn't 
> provide it, and you must remove it for the application to run, then yes, the 
> software will be less secure as a result.  This shouldn't be difficult to 
> understand.

I understand but disagree.

> 
> No, but it is a useful security layer to control access.

The utility of *this particular mechanism* does not justify the cost of 
maintaining it.
The question isn’t if such a mechanism could be useful or not, but is this the 
best use of resources to improve security?
In other words, the choice isn’t between this and nothing, but between this and 
everything else.

> 
> It is not possible to implement fine grained access control in Java, or as a 
> library, this feature is low level JVM code.

Again, when you say fine-grained level access control you don’t mean 
fine-grained level access control but the
particular features provided by the Security Manager; and those features — at 
least those you sound most interested
in — are not low-level JVM code, and can be implemented in Java with a Java 
agent, at least as an additional, albeit
imperfect layer of security, if you think this is a worthwhile and 
cost-effective approach.

> 
> Developers who wish to develop new applications that require access control 
> should do so using another platform, those who have existing software 
> deployments, need to stay on Java 17 for example, indefinitely until EOL.

I strongly disagree; the Security Manager is not the only — and I would say 
it’s not even the best — way to 
offer access control. This JEP proposes removing Security Manager. That that 
implies giving up on access control 
is entirely your insistence on identifying the two. And if the only way you can 
think of implementing access 
control is with a call-stack code-sourcing mechanism, then I’m afraid other 
platforms are not going to offer it, 
because they also don’t share the view that this is the best, let alone the 
only, way to do this. 

> 
> New developments that require access control might consider the Microsoft CLR 
> for example, however I'm no expert, there may be better alternatives. 
> https://urldefense.com/v3/__https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEF_yAtVXw$
>  

.NET have also dropped their analogous mechanism; they, too, have become 
convinced that different permissions 
to different code *in the same process* is not a the best approach to security 
today in cost/benefit. 
Erlang, another platform with a strong emphasis on distributed systems also 
does not provide this mechanism. I am not
aware of any platform that does.

> 
> To restrict operations to the principle of least privilege.

The principles are known, but not every additional layer is worth it at any 
cost. 

> 
> The code is not known at compile time, it is dynamic, such that it is only 
> known at runtime, this means that to use the Java Agent mechanism, one must 
> intercept every network and file system access, then try to determine where 
> the call originates, to see whether it can be allowed or disallowed.

The Java agent can insert the same instrumentation points as the Security 
Manager in JDK code, and the equivalent
of protection domains will be determined by the framework and stored and 
manipulated as

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries




On 18/05/2021 12:25 am, Ron Pressler wrote:



On 17 May 2021, at 13:47, Peter Firmstone  wrote:

It is a foundational feature, it has a significant impact on those who adopted 
it.

True. But the problem is that it also has a significant impact on those who 
didn’t.



Yes, you are talking about those who maintain and develop OpenJDK, but 
this is only a small proportion of the overall Java developer 
ecosystem.    But I understand that this isn't insignificant either, 
just like the features removal isn't insignificant to those affected by it.


Out of curiosity, was anyone here impacted by the oil pipeline shutting 
down?   Impacts can be direct and indirect.







This is an existing system, your arguments are not relevant as the cost of 
rewriting millions of lines of code is prohibitively expensive.

I don’t think we’re talking about rewriting millions of lines of code, and the 
cost of keeping
Security Manager is far greater, anyway. We want to shift the high cost of 
maintaining the
SM, or something like it, from those who *don’t* want it to those who do, and I 
think that’s more
than fair.



No, it's not practical, but there's no viable upgrade path, so our only 
option is indefinite maintenance of Java 17.






My point is that there will be no restriction on the services themselves in the 
JVM consuming and using the services.  Currently service proxy's are only 
allowed to contact their originating server and negotiate a few required 
permissions for their operation.  In future versions of Java without a 
SecurityManager, they will have no restrictions at all.

I don’t understand this statement. Which JDK-implemented “service proxies” are 
you referring to that
today implement such a restriction in the JDK?



In a distributed system that uses POJO's and Remote Method Invocation, a 
proxy is used to invoke methods on an object in a remote JVM or any 
other language for that matter, operating in another node or process.   
The proxy implementation is not known, nor necessarily are it's 
communication methods until runtime.  It is loaded dynamically.


The proxy is trusted code (each implementation has different bytecode), 
but we wish to run it with principles of least privilege, rather than an 
anything goes approach.


https://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS





Yes, it is the case for software that was designed to use the SecurityManager.  
 We need to be honest about the impact, yes I understand SecurityManager will 
be removed, however telling developers their EXISTING software is no less 
secure is inaccurate.


It is accurate, because if existing software picks a new runtime, then it will 
have to be modified
in order to run at all, if only to acknowledge it is depending on a deprecated, 
and later, degraded
feature. This JEP is proposing a responsible mechanism precisely to prevent 
situations like applications
that do depend on SM for security suddenly become less secure without their 
knowledge.



If the application needs access control, but the Java platform doesn't 
provide it, and you must remove it for the application to run, then yes, 
the software will be less secure as a result.  This shouldn't be 
difficult to understand.


So you could say, that the application has become less secure, with 
their knowledge, because it has a task to perform and it will be made so 
that it will continue to perform that task, even at the expense of less 
security, because security has become the obstacle to operation, which 
is the primary purpose, so security becomes a secondary concern.  No one 
will switch it off if it's insecure, at least not until after they're 
hacked, then they'll look for bolt on security solutions and they may 
get approval to rewrite the system at that stage.






Are you a security expert?  Is this your opinion as a security expert?

I am absolutely not a security expert, which is why I talk to security experts 
who tell me
they do not recommend the Security Manager as a central security measure.



No, but it is a useful security layer to control access.

Security should be seen as a layered approach, rather than one solution 
fits everything.   Each layer has it's role to play.


The use of SecurityManager as a central security measure is not the intent.

https://www.upguard.com/blog/principle-of-least-privilege

Yes the Java Permission model is flawed, one cannot disallow an insecure 
network connection, while allowing a secure TLS authenticated 
connection, however we've created other ways of doing that, but it does 
rely on the Permission model to limit privilege.







Your proposal is quite plain and simple, I don't see how it can be 
misunderstood, you propose to remove the ability to make stack based domain, 
access control decisions.

Not the ability, but the built-in implementation.



It is not possible to implement fine grained access control in Java, or 
as a library, this feature is low level JVM code.


Developers who wish to

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 17 May 2021, at 13:47, Peter Firmstone  wrote:
> 
> It is a foundational feature, it has a significant impact on those who 
> adopted it.

True. But the problem is that it also has a significant impact on those who 
didn’t.

> 
> 
> This is an existing system, your arguments are not relevant as the cost of 
> rewriting millions of lines of code is prohibitively expensive.

I don’t think we’re talking about rewriting millions of lines of code, and the 
cost of keeping
Security Manager is far greater, anyway. We want to shift the high cost of 
maintaining the
SM, or something like it, from those who *don’t* want it to those who do, and I 
think that’s more
than fair.

> 
> My point is that there will be no restriction on the services themselves in 
> the JVM consuming and using the services.  Currently service proxy's are only 
> allowed to contact their originating server and negotiate a few required 
> permissions for their operation.  In future versions of Java without a 
> SecurityManager, they will have no restrictions at all.

I don’t understand this statement. Which JDK-implemented “service proxies” are 
you referring to that
today implement such a restriction in the JDK?

> 
> Yes, it is the case for software that was designed to use the 
> SecurityManager.   We need to be honest about the impact, yes I understand 
> SecurityManager will be removed, however telling developers their EXISTING 
> software is no less secure is inaccurate.
> 

It is accurate, because if existing software picks a new runtime, then it will 
have to be modified
in order to run at all, if only to acknowledge it is depending on a deprecated, 
and later, degraded
feature. This JEP is proposing a responsible mechanism precisely to prevent 
situations like applications
that do depend on SM for security suddenly become less secure without their 
knowledge.

> 
> Are you a security expert?  Is this your opinion as a security expert?

I am absolutely not a security expert, which is why I talk to security experts 
who tell me
they do not recommend the Security Manager as a central security measure.

> 
> Your proposal is quite plain and simple, I don't see how it can be 
> misunderstood, you propose to remove the ability to make stack based domain, 
> access control decisions.

Not the ability, but the built-in implementation.

> 
> These sandboxes you talk of, I have not seen any practical workable 
> solutions, I'm assuming your talking about Intel architecture based Virtual 
> Machines that host an OS, they don't provide dynamic access decisions for 
> Java?  Yes I acknowledge they can do static, but not dynamic performant 
> access decisions.

Depends what you mean by “dynamic.” They do not attempt to provide different 
access to JDK capabilities
to different code-paths within the same Java process, which is why they are 
preferable.

> 
> We should just say, that there is no future migration path for existing Java 
> applications that require fine grained access control.

But that is untrue. First, let’s clarify that by “fine-grained access control” 
you don’t mean the
ability of an application to allow or disallow application-level operations on 
as fine a level as they’d
like based on, say, user credentials, but on the JDK blocking *JDK-level* 
operations based on the code
paths that invoke them. Second, while the JEP does not offer a built-in 
replacement for such a mechanism,
because few people want it and we believe it is not a good path for security 
for Java these days, 
if you absolutely want such a mechanism, you can inject instrumentation to 
replace the built-in one
using the Java Agent mechanism, so there is a migration path even for this use 
case.

That taking this particular migration path rather than opting for other 
security measures is not trivial
only demonstrates why the Security Manager needs to be removed, as the people 
paying for that work now
are those who *don’t* want it.

> 
> I think for starters we should discourage those who require fine grained 
> access control from using newer versions of Java that don't implement it.   
> Then it would be nice for those who would like to help maintain an existing 
> version of Java that does support fine grained access control to do so as a 
> part of the OpenJDK project.
> 
> I don't understand why this is so objectionable?

Because your very specific and FAR from universal definition of “fine-grained 
access control” does
all the work in this statement. It is not objectionable to say that Java will 
not provide a built-in
mechanism that filters certain JDK operations based on the code-paths in which 
they are accessed.

> 
> It really doesn't matter what 99.99% of other people are doing for the 0.01% 
> that use it.  You conveniently plucked these figures out of thin air, a word 
> of advice, it lessens the credibility of your arguments.

It is not my intention to convince you personally that the proposal is 
justified. If you’d like to see the

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries


Some quick clarifications, I'll try to reply properly in the next few days.

On 17/05/2021 9:29 pm, Ron Pressler wrote:



On 17 May 2021, at 06:19, Peter Firmstone  wrote:


In versions of Java, without a security manager, the third party service 
provider will have AllPermission, and the user will have restricted permissions 
(if we still have some form of user Permission based access control).

Follow this issue: https://bugs.openjdk.java.net/browse/JDK-8266592



Thanks for the link, I am aware of it.





So basically we might as well remove all access control completely and say that 
all users and all code is completely trusted,

All users — no, and at this point I’m starting to think that, rather than 
trying to understand
the direction proposed here, which is ultimately meant to help make Java *more* 
secure, you’re
trying to intentionally misunderstand and/or misrepresent it.


I understand the direction and the reasons for the decision, however we 
still need to consider how it will impact those who utilise it, and I'm 
sure more examples will come to light in time.


In my case, yes of course it will be less secure, because I'm using the 
stack context to manage access decisions for remote service identity.   
These service proxy's now have some very limited permissions, in future 
their access will be completely unrestricted.   It is a foundational 
feature, it has a significant impact on those who adopted it.







It does appear that a side effect of JEP 411, perhaps even an unintended 
consequence, will be to limit Java to trusted networks with one administrator.  
It is most certainly appears to be a single JVM focused change, or a system 
controlled by one administrator.

Absolutely not. 99.99% of secure distributed systems in the world, written in 
Java or not,
do not use Java’s Security Manager, and a great many of them mix of Java and 
other runtimes.

You might have a point, though, that the current direction does not try to 
tailor a specific
solution to distributed systems made *only* of JVMs, and, because systems are 
not controlled by
one administrator, and because many are polyglot, mixing services running on 
different runtimes,
this is very much the right direction to go. You, on the other hand, seem to be 
focused on
“Java only” systems.


This is an existing system, your arguments are not relevant as the cost 
of rewriting millions of lines of code is prohibitively expensive.


Services written in other languages may be providers of services, 
however other language runtimes may not be consumers of services because 
most lack dynamic class loading or dynamic fine grained access 
control.   The JVM is required to allow services to be agglomerated into 
a system.


My point is that there will be no restriction on the services themselves 
in the JVM consuming and using the services.  Currently service proxy's 
are only allowed to contact their originating server and negotiate a few 
required permissions for their operation.  In future versions of Java 
without a SecurityManager, they will have no restrictions at all.







Newer versions of Java will of course be less secure without access controls 
and unsuitable for use in a distributed system that involves more than one 
administrator.

Of course not.


Yes, it is the case for software that was designed to use the 
SecurityManager.   We need to be honest about the impact, yes I 
understand SecurityManager will be removed, however telling developers 
their EXISTING software is no less secure is inaccurate.





I realise you’re trying to paint a picture as if the removal of Security 
Manager, a barely used
component, would adversely affects Java security — contrary to the opinion of 
security experts — b
ut the fact is that the vast majority of Java systems today already use other 
security
measures, including sandboxes. I don’t know if you actually believe this, in 
which case you
misunderstand the proposal, or don’t believe it but think that such claims 
would sound convincing
to others.

It is true that we’re saying to those few remaining people who still depend on 
Java’s internal
sandbox to do what most other people have already done and rely on other 
security measures, and so
*if they do not* their systems will be less secure, but, of course, this is not 
what’s being
recommended. All this JEP is saying that the JDK itself will not, in the long 
term, provide this
particular fine-grained sandbox, and that remaining users should switch to 
other sandboxes available
to Java applications.



Barely used or not, it is only fair to acknowledge the impact on those 
who do use it.


Are you a security expert?  Is this your opinion as a security expert?

I don't need a sandbox, I need access control.

Your proposal is quite plain and simple, I don't see how it can be 
misunderstood, you propose to remove the ability to make stack based 
domain, access control decisions.


These sandboxes you talk of, I have not seen any

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

I would say that trying to mitigate attacks on vulnerabilities in trusted code 
based on specific code paths is 
not recommended. You’re trying to preemptively defend agains something complex 
— a security bug — with 
another complex mechanism. Even if you do happen to defend against a particular 
attack attempt due to a bug
that happens to be in the “less trusted” code rather than in the more trusted 
code, the cost/benefit to this 
approach is not very attractive, in my opinion.

I think it is easier and simpler (and so more secure) to not differentiate 
codepaths in the same process, grant
whatever minimal privileges are required to the entire process with more 
watertight mechanisms than the SM, 
and then actively monitor it — say, with streaming JFR events, which will be 
made richer, and already do
expose the stack trace — for suspicious activity. If a bug is found — fix it.

If your application clearly has more trusted/less exposed components and less 
trusted/less exposed ones,
and you feel that they must be separated for security reasons, consider running 
them in different processes. 
Process isolation is a more secure, better studied, and better supported 
security mechanism than the Security Manager.

— Ron

> On 17 May 2021, at 03:11, David Black  wrote:
> 
> Hi Ron
> 
> On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
>> 
>> 
>> 
>>> On 13 May 2021, at 03:11, David Black  wrote:
>>> 
>>> 
>>> This seems somewhat more useful than 1 & 2 but imho it would be better to 
>>> be able to perform checks/grant access on a call stack basis.
>> 
>> This is an important point we’re trying to get across. The very reason the 
>> Security Manager was made this
>> way is because it does *seem* better; certainly it is much more flexible. 
>> However, twenty five years of
>> experience have shown us that *in practice* this is not the case, certainly 
>> not when you look at the
>> ecosystem as a whole. It is hard to get right, which results in people not 
>> using the mechanism (which
>> significantly reduces its utility and the value in maintaining it), or 
>> worse, use it and think it gets
>> the job done, but actually use it incorrectly, providing the illusion of 
>> security without actual security.
> 
> Agreed, but if you don't have this level of introspection/detail how
> do you propose to, at least partially, mitigating bug classes such as
> SSRF?
> 
>>> Atlassian currently makes use of a security manager to prevent access to 
>>> cloud metadata services that do not have an amazon sdk related class on the 
>>> call stack. This helps to mitigate the impact of SSRF in applications 
>>> running in a cloud environment 
>>> (https://urldefense.com/v3/__https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager__;!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PHR4-37A$
>>>  ).
>> 
>> 
>> We’re talking about a situation where *all* the classes running in your 
>> application are trusted,
>> i.e. assumed to not be malicious, and that an accidental vulnerability might 
>> exist in any one of them.
>> Can you explain why you believe this mechanism, that treats different 
>> classes differently is the best
>> way to improve security?
> 
> Because it allows for restrictions to be placed upon "trusted"[0]
> classes so as to offer some mitigation against classes of bugs such as
> SSRF. You can also use a security manager to monitor for potential
> policy implementation issues & make adjustments. Specifically for
> SSRF, if you want to mitigate the issue you need to ensure that
> network connections being made respect proxy settings but also allow
> support for certain code paths bypassing proxy settings to access
> potentially sensitive network locations (e.g. cloud metadata
> resources) this can result in mistakes in configuration occurring and
> or finding libraries/classes that ignore proxy configuration. You may
> be thinking "oh but surely no library/class would have proxy
> problems?" well that answer is "yes they can and do". For example,
> https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
> 9 but has not yet been fixed in java 8[2]. In a similar fashion,
> OkHttp before version 3.5.0 could also fallback back to a direct
> connection[3]. So having a "belt and braces", prox(y|ies) and a
> security manager, approach is valuable.
> 
> 
> [0] "Trusted" classes are not immune to security issues
> [1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
> [2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
> &  
> https://urldefense.com/v3/__https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java*L1180__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PCT2HmkQ$
>  
> [3] 
>

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 17 May 2021, at 06:19, Peter Firmstone  wrote:
> 
> 
> In versions of Java, without a security manager, the third party service 
> provider will have AllPermission, and the user will have restricted 
> permissions (if we still have some form of user Permission based access 
> control).  

Follow this issue: https://bugs.openjdk.java.net/browse/JDK-8266592

> So basically we might as well remove all access control completely and say 
> that all users and all code is completely trusted, 

All users — no, and at this point I’m starting to think that, rather than 
trying to understand
the direction proposed here, which is ultimately meant to help make Java *more* 
secure, you’re
trying to intentionally misunderstand and/or misrepresent it.

> 
> It does appear that a side effect of JEP 411, perhaps even an unintended 
> consequence, will be to limit Java to trusted networks with one 
> administrator.  It is most certainly appears to be a single JVM focused 
> change, or a system controlled by one administrator.

Absolutely not. 99.99% of secure distributed systems in the world, written in 
Java or not,
do not use Java’s Security Manager, and a great many of them mix of Java and 
other runtimes.

You might have a point, though, that the current direction does not try to 
tailor a specific
solution to distributed systems made *only* of JVMs, and, because systems are 
not controlled by 
one administrator, and because many are polyglot, mixing services running on 
different runtimes, 
this is very much the right direction to go. You, on the other hand, seem to be 
focused on
“Java only” systems.

> 
> Newer versions of Java will of course be less secure without access controls 
> and unsuitable for use in a distributed system that involves more than one 
> administrator.

Of course not.

I realise you’re trying to paint a picture as if the removal of Security 
Manager, a barely used 
component, would adversely affects Java security — contrary to the opinion of 
security experts — b
ut the fact is that the vast majority of Java systems today already use other 
security 
measures, including sandboxes. I don’t know if you actually believe this, in 
which case you
misunderstand the proposal, or don’t believe it but think that such claims 
would sound convincing
to others.

It is true that we’re saying to those few remaining people who still depend on 
Java’s internal 
sandbox to do what most other people have already done and rely on other 
security measures, and so
*if they do not* their systems will be less secure, but, of course, this is not 
what’s being
recommended. All this JEP is saying that the JDK itself will not, in the long 
term, provide this
particular fine-grained sandbox, and that remaining users should switch to 
other sandboxes available
to Java applications.

— Ron

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-16 Thread Peter Firmstone

Although JGDMS is a different type of system, this is one of the 
functions of SecurityManager in our system also.


We have methods equivalent to Subject.doAs, which instead of injecting 
the privileges of the user into all ProtectionDomain's, instead prepends 
a ProtectionDomain that represents the user's Subject onto the call 
stack.  When used in this way, it changes policy file permission 
grant's, it actually simplifies them, because you can grant 
AllPermission to trusted code, if you want to, and then limit user 
permissions and it will restrict only the user, however this doesn't 
fully explain why we do this.


https://pfirmstone.github.io/JGDMS/jgdms-platform/apidocs/net/jini/security/Security.html#doAs-javax.security.auth.Subject-java.security.PrivilegedAction- 



To explain this, requires briefly revisiting the 8 fallacy's of 
distributed computing, that is, item 6, there is only one administrator.


So for your single JVM server, or many instances of JVM's operating 
independently, yes, there is only one administrator, but this is not the 
case for a distributed system.


The reason we prepend a ProtectionDomain representing the user, is that 
there are ProtectionDomain's on the stack that represent Services other 
administrators are responsible for, it just happens to be proxy "code" 
that implements an interface, or interfaces, used for method calls 
between the two systems.  These proxy's are assigned a ClassLoader based 
on the Server's security constraints, the server Endpoint address (by 
the proxy's InvocationHandler implementation) and the codebase annotation.


So it's not really about the code, it's about the Service's identity and 
keeping the identities of different services separated from each other 
(even those using the same proxy code, with different server identity, 
eg for lookup services from different entities) and users, to avoid 
granting those Services all the users permissions while also allowing 
the user to authenticate with the service and also run as a logged in 
subject in threads on the remote node as well.


As previously explained, the permission's required for Service proxy's 
are negotiated dynamically at runtime, between the two parties.  We 
don't grant all the permissions the user has to the remote service 
provider, only those that have been negotiated, when a secure connection 
was first established, so the user allows the service provider to 
utilise some of the users permissions. The service provider cannot 
currently obtain more permission than the user has.


In versions of Java, without a security manager, the third party service 
provider will have AllPermission, and the user will have restricted 
permissions (if we still have some form of user Permission based access 
control).   So basically we might as well remove all access control 
completely and say that all users and all code is completely trusted, 
the system will be much more user friendly and easier to use, but 
legally that can present problems.


It does appear that a side effect of JEP 411, perhaps even an unintended 
consequence, will be to limit Java to trusted networks with one 
administrator.  It is most certainly appears to be a single JVM focused 
change, or a system controlled by one administrator.


Newer versions of Java will of course be less secure without access 
controls and unsuitable for use in a distributed system that involves 
more than one administrator.


In a way, it's ironic, IPv4 limited us to local networks, but now it 
looks like later versions of Java will now be the limiting factor.


I realize less utilized platform features like access controls aren't 
the concern of OpenJDK developers, but it doesn't appear to be doing any 
harm talking about them, at least so the consequences of the decision 
can be better understood.   I realize this is probably a business and 
marketing based decision.  I guess Java has more of an enterprise 
history, and it's giving that up to become leaner and more developer 
friendly (less things to learn or understand).


Cheers,

Peter.

On 17/05/2021 12:11 pm, David Black wrote:

Hi Ron

On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:




On 13 May 2021, at 03:11, David Black  wrote:


This seems somewhat more useful than 1 & 2 but imho it would be better to be 
able to perform checks/grant access on a call stack basis.

This is an important point we’re trying to get across. The very reason the 
Security Manager was made this
way is because it does *seem* better; certainly it is much more flexible. 
However, twenty five years of
experience have shown us that *in practice* this is not the case, certainly not 
when you look at the
ecosystem as a whole. It is hard to get right, which results in people not 
using the mechanism (which
significantly reduces its utility and the value in maintaining it), or worse, 
use it and think it gets
the job done, but actually use it incorrectly, providing the illusion of 
security without

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-16 Thread David Black

Hi Ron

On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
>
>
>
> > On 13 May 2021, at 03:11, David Black  wrote:
> >
> >
> > This seems somewhat more useful than 1 & 2 but imho it would be better to 
> > be able to perform checks/grant access on a call stack basis.
>
> This is an important point we’re trying to get across. The very reason the 
> Security Manager was made this
> way is because it does *seem* better; certainly it is much more flexible. 
> However, twenty five years of
> experience have shown us that *in practice* this is not the case, certainly 
> not when you look at the
> ecosystem as a whole. It is hard to get right, which results in people not 
> using the mechanism (which
> significantly reduces its utility and the value in maintaining it), or worse, 
> use it and think it gets
> the job done, but actually use it incorrectly, providing the illusion of 
> security without actual security.

Agreed, but if you don't have this level of introspection/detail how
do you propose to, at least partially, mitigating bug classes such as
SSRF?

> > Atlassian currently makes use of a security manager to prevent access to 
> > cloud metadata services that do not have an amazon sdk related class on the 
> > call stack. This helps to mitigate the impact of SSRF in applications 
> > running in a cloud environment 
> > (https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager).
>
>
> We’re talking about a situation where *all* the classes running in your 
> application are trusted,
> i.e. assumed to not be malicious, and that an accidental vulnerability might 
> exist in any one of them.
> Can you explain why you believe this mechanism, that treats different classes 
> differently is the best
> way to improve security?

Because it allows for restrictions to be placed upon "trusted"[0]
classes so as to offer some mitigation against classes of bugs such as
SSRF. You can also use a security manager to monitor for potential
policy implementation issues & make adjustments. Specifically for
SSRF, if you want to mitigate the issue you need to ensure that
network connections being made respect proxy settings but also allow
support for certain code paths bypassing proxy settings to access
potentially sensitive network locations (e.g. cloud metadata
resources) this can result in mistakes in configuration occurring and
or finding libraries/classes that ignore proxy configuration. You may
be thinking "oh but surely no library/class would have proxy
problems?" well that answer is "yes they can and do". For example,
https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
9 but has not yet been fixed in java 8[2]. In a similar fashion,
OkHttp before version 3.5.0 could also fallback back to a direct
connection[3]. So having a "belt and braces", prox(y|ies) and a
security manager, approach is valuable.

[0] "Trusted" classes are not immune to security issues
[1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
[2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
&  
https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1180
[3] https://square.github.io/okhttp/changelog_3x/#version-350

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-14 Thread Peter Firmstone




On 13/05/2021 10:59 pm, Sean Mullan wrote:


The JEP does have a section on this:

"In future JDK releases, we may degrade the Security Manager APIs so 
that they remain in place but have 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 would allow libraries that support the Security 
Manager and were compiled against previous Java releases to continue 
to work without change or even recompilation. Once the compatibility 
risk has declined to an acceptable level, we expect to remove the APIs."


So, if the JEP is targeted to 17, then the Security Manager will be 
deprecated for removal but will still be fully functional and 
supported in 17.


*Disclaimer: The next part is forward thinking, and subject to change.*

Once we start degrading the APIs, the functionality of the Security 
Manager may not fully work as before, so in that sense you might 
consider it "removed". We don't yet have a definitive timeline for 
that, it may occur in the next release, or it may not, but it will 
probably occur within a few releases after the release it is targeted to.


--Sean

It will be important for existing JAAS login mechanisms and 
AccessControlContext's for Subject's are still functional and preserved 
so that TLS clients and servers can authenticate.   The 
AccessControlContext would only need to contain an array with only one 
ProtectionDomain, containing the Subject.



--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-14 Thread Peter Firmstone


Thanks for confirming.

Cheers,

Peter.

On 13/05/2021 10:59 pm, Sean Mullan wrote:



On 5/13/21 6:00 AM, Ron Pressler wrote:



On 13 May 2021, at 10:32, Peter Firmstone 
 wrote:


So it targets 17.


I don’t know. I think that’s still TBD, but perhaps others know more.


At this point, yes, we are planning to target the JEP to JDK 17.

It would be nice to have certainty about which release it will be 
removed from, for planning purposes.   Again it would seem that this 
isn't a consideration of OpenJDK.


It very much is, which is why we have the deprecation and removal 
policy. Please
read the JEP carefully. In addition to deprecation and removal, this 
JEP also proposes
an interim step of degradation prior to removal. Removal, as the JEP 
says, will only
be done once it no longer poses a big compatibility threat. At the 
fastest pace possible
removal is more than a year away, though it will likely be longer 
than that.


The JEP does have a section on this:

"In future JDK releases, we may degrade the Security Manager APIs so 
that they remain in place but have 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 would allow libraries that support the Security 
Manager and were compiled against previous Java releases to continue 
to work without change or even recompilation. Once the compatibility 
risk has declined to an acceptable level, we expect to remove the APIs."


So, if the JEP is targeted to 17, then the Security Manager will be 
deprecated for removal but will still be fully functional and 
supported in 17.


*Disclaimer: The next part is forward thinking, and subject to change.*

Once we start degrading the APIs, the functionality of the Security 
Manager may not fully work as before, so in that sense you might 
consider it "removed". We don't yet have a definitive timeline for 
that, it may occur in the next release, or it may not, but it will 
probably occur within a few releases after the release it is targeted to.


--Sean





Is there an OpenJDK community project group that maintains older 
Java versions I can join?




Yes, that would be the Updates Project.

— Ron

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-13 Thread Peter Firmstone


I also think good developers will add these security features.

The problem is that Permissions are currently used to regulate access 
control because this is how we've been told it should be done for over 
20 years.


Now maybe people aren't using the Java FilePolicy provider (for reasons 
stated previously), but as has been discovered, they often will override 
SecurityManager and implement some form of access control on trusted 3rd 
party code.


Trusted code - Developed by people with good intentions - includes third 
party library code, we check it for known vulnerabilities at build time 
using OWASP, but we don't audit it ourselves as this requires 
understanding how the internals work and we are using it like a black 
box.  If we have concerns we might perform static analysis, but we don't 
do that for dynamic code, eg maven dependencies and then we are 
powerless to do anything about it, other than report the bug, so access 
control can be used to mitigate until it's fixed, or we can use the 
principle of least privilege so we are not impacted by it.


Java Serialization is also a form of parsing information, just like PDF 
documents and other file formats, problems with the Sandbox; there was 
no Permission to limit which classes could be deserialized, and JVM code 
always has AllPermission, so we couldn't restrict it either.  
Additionally there was no ProtectionDomain to represent the data being 
deserialized, and whether it was trusted or untrusted, these security 
features wouldn't have been difficult to add, however we rely on the 
platform developers to see the benefits.  We are all only human.


In JGDMS there are constraints we apply to services which require 
authentication and encryption, which must be met before deserialization 
or any downloads can proceed.


In our re-implementation of Atomic Java Serialization, we use a 
DeserizablePermission, to limit which libraries can perform 
de-serialization.   This is in addition to the use of failure atomic 
constructors, so we don't break object encapsulation.


We also perform static analysis at build time and fix these bugs too.

SecurityManager has much influence in access decisions in our software, 
we won't have the resources to upgrade, there's a massive amount of 
security auditing required before we could even consider it.   Our only 
option is to participate in the maintenance of existing Java versions.   
Java will be our COBOL. We will be capable of using Java 1.8 to 1.17, 
but not Java 2.0 (after disablement occurs).


Obviously removing SecurityManager infrastructure from OpenJDK is a 
significant undertaking requiring significant resources to audit the 
impacts of removal of Permission checks, unfortunately we don't have 
these resources and the alternative methods of putting alternative 
access controls in place isn't obvious and will require research, as you 
state below, I know very little about how this can be done without using 
existing Java access controls.


I think during this transition period, while developers are 
reestablishing what constitutes secure programming, there will be many 
new bugs exposed that SecurityManager was obscuring.


Personally, I will be observing from the sidelines to learn new security 
features and best practices I'm not yet aware of.  It's always best to 
wait and see the outcome of experiments before diving in.


The problem with Security is many developers don't like it, or want it 
to be someone else's problem, so we will always have reasons to remove 
whatever Security API's are added to Java because of limited use.


Perhaps I'm conflating security with access control again?

--
Regards,
 
Peter


On 14/05/2021 2:15 am, Sean Mullan wrote:



On 5/12/21 5:41 PM, Peter Tribble wrote:

Let me give a concrete example:

Parsing and rendering a PDF file that may contain references to fonts 
or other resources.
We know exactly where the files are installed, so wish to allow the 
rendering routine access
to the fonts it will need. But not to any other files, and not 
(normally) to network resources at
all. Note that we trust the code, but not necessarily the document 
it's parsing. (Although the
document itself may be perfectly well formed - document formats often 
allow embedding

references to 3rd-party objects, undesirable as that may be.)

There are a range of such issues in document parsing and rendering. 
And unfortunately, the
good libraries for this task are proprietary so we can't modify them 
to apply the restrictions
we're after. The (server-side) application does need access to files 
and network resources at
other times; it's only when it goes into the rendering step that we 
lock it down, and unlock it

once done.


I know very little about this area, but I would think a good PDF 
rendering library would include security features which prevent 
arbitrary file/network access from untrusted documents by default or 
at least give you the ability to control that.


--Sean

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-13 Thread Sean Mullan





On 5/12/21 5:41 PM, Peter Tribble wrote:

Let me give a concrete example:

Parsing and rendering a PDF file that may contain references to fonts or 
other resources.
We know exactly where the files are installed, so wish to allow the 
rendering routine access
to the fonts it will need. But not to any other files, and not 
(normally) to network resources at
all. Note that we trust the code, but not necessarily the document it's 
parsing. (Although the
document itself may be perfectly well formed - document formats often 
allow embedding

references to 3rd-party objects, undesirable as that may be.)

There are a range of such issues in document parsing and rendering. And 
unfortunately, the
good libraries for this task are proprietary so we can't modify them to 
apply the restrictions
we're after. The (server-side) application does need access to files and 
network resources at
other times; it's only when it goes into the rendering step that we lock 
it down, and unlock it

once done.


I know very little about this area, but I would think a good PDF 
rendering library would include security features which prevent 
arbitrary file/network access from untrusted documents by default or at 
least give you the ability to control that.


--Sean

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-13 Thread Bernd Eckenfels

Just to add another point to this. Today it is quite hard to use operating 
system facilities like chroot/jails, security tokens, seteuid, dropping 
priveledges or switching Security tokens which would allow to limit or escalate 
priveledges in an OS enforced manor. If we would have a bit more support of 
that, some sandbox mechanisms might actually be able to replace a security 
manager and/or open new features like processing workload with actual user 
accounts, etc.

I am however not sure what mechanism would be needed (and possible given the 
complete runtime) for that and how to make it able to support multiple OS with 
that. Maybe it would be an os specific optional facility? Something like SAPs 
shared memory with multiple processes maybe as an option for easy spawning of 
contained worklads?

--
http://bernd.eckenfels.net

Von: security-dev  im Auftrag von Peter 
Tribble 
Gesendet: Thursday, May 13, 2021 9:25:25 AM
An: Ron Pressler 
Cc: Alan Bateman ; Peter Firmstone 
; security-dev@openjdk.java.net 

Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring / 
restricting libraries

On Wed, May 12, 2021 at 10:49 PM Ron Pressler 
mailto:ron.press...@oracle.com>> wrote:

> On 12 May 2021, at 22:41, Peter Tribble 
> mailto:peter.trib...@gmail.com>> wrote:
>
> Let me give a concrete example:
>
> Parsing and rendering a PDF file that may contain references to fonts or 
> other resources.
> We know exactly where the files are installed, so wish to allow the rendering 
> routine access
> to the fonts it will need. But not to any other files, and not (normally) to 
> network resources at
> all. Note that we trust the code, but not necessarily the document it's 
> parsing. (Although the
> document itself may be perfectly well formed - document formats often allow 
> embedding
> references to 3rd-party objects, undesirable as that may be.)
>

Thank you. Let me ask you this, then:

1. Would allowing access to certain files and no network for the *entire* 
application be
sufficient? Consider that you can run some code in a separate Java process with 
OS protections.
If not, why not?

Unfortunately not. We're already running this in a separate sandboxed Java 
process to provide a
basic level of isolation. But that process has to interact with the outside 
world - it has to get the
file in the first place, and put the result somewhere (which may be to a 
filesystem or to a networked
system such as S3). Generally, the permitted level of access will vary 
depending on where we are
in the rendering process.

2. Would turning such access on and off for the entire application through some 
Java process
be sufficient?

That's effectively what we're doing right now. Essentially we do:

doRender() {
  installSecurityManager();
  do3rdPartyRender();
  uninstallSecurityManager();
}

which is fine because we are in a dedicated sandbox and can be sure that we 
aren't doing anything else
at the time.

3. Would controlling such access on a per-thread basis be sufficient?

In a way, that would be more flexible, as we wouldn't need the stop-the-world 
blanket restriction.
It does, however, rely on the assumption that once you've applied the 
restriction to a thread then
the do3rdPartyRender() and anything it calls is also restricted to that thread.

In our specific use case, because we have separate processes already, we would 
probably aim for 2
rather than 3. But I can certainly see why 3 is attractive in general - it 
allows you to tie a restriction to
a given execution context.

Please don’t read 2 or 3 as some concrete proposals; I’m just trying to 
understand the requirements.

— Ron

Thanks,

--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-13 Thread Sean Mullan





On 5/13/21 6:00 AM, Ron Pressler wrote:




On 13 May 2021, at 10:32, Peter Firmstone  wrote:

So it targets 17.


I don’t know. I think that’s still TBD, but perhaps others know more.


At this point, yes, we are planning to target the JEP to JDK 17.


It would be nice to have certainty about which release it will be removed from, 
for planning purposes.   Again it would seem that this isn't a consideration of 
OpenJDK.


It very much is, which is why we have the deprecation and removal policy. Please
read the JEP carefully. In addition to deprecation and removal, this JEP also 
proposes
an interim step of degradation prior to removal. Removal, as the JEP says, will 
only
be done once it no longer poses a big compatibility threat. At the fastest pace 
possible
removal is more than a year away, though it will likely be longer than that.


The JEP does have a section on this:

"In future JDK releases, we may degrade the Security Manager APIs so 
that they remain in place but have 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 would allow libraries that support the Security Manager and 
were compiled against previous Java releases to continue to work without 
change or even recompilation. Once the compatibility risk has declined 
to an acceptable level, we expect to remove the APIs."


So, if the JEP is targeted to 17, then the Security Manager will be 
deprecated for removal but will still be fully functional and supported 
in 17.


*Disclaimer: The next part is forward thinking, and subject to change.*

Once we start degrading the APIs, the functionality of the Security 
Manager may not fully work as before, so in that sense you might 
consider it "removed". We don't yet have a definitive timeline for that, 
it may occur in the next release, or it may not, but it will probably 
occur within a few releases after the release it is targeted to.


--Sean





Is there an OpenJDK community project group that maintains older Java versions 
I can join?



Yes, that would be the Updates Project.

— Ron

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-13 Thread Ron Pressler

> On 13 May 2021, at 03:11, David Black  wrote:
> 
> 
> This seems somewhat more useful than 1 & 2 but imho it would be better to be 
> able to perform checks/grant access on a call stack basis.

This is an important point we’re trying to get across. The very reason the 
Security Manager was made this
way is because it does *seem* better; certainly it is much more flexible. 
However, twenty five years of
experience have shown us that *in practice* this is not the case, certainly not 
when you look at the 
ecosystem as a whole. It is hard to get right, which results in people not 
using the mechanism (which
significantly reduces its utility and the value in maintaining it), or worse, 
use it and think it gets
the job done, but actually use it incorrectly, providing the illusion of 
security without actual security.

> Atlassian currently makes use of a security manager to prevent access to 
> cloud metadata services that do not have an amazon sdk related class on the 
> call stack. This helps to mitigate the impact of SSRF in applications running 
> in a cloud environment 
> (https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager).

We’re talking about a situation where *all* the classes running in your 
application are trusted,
i.e. assumed to not be malicious, and that an accidental vulnerability might 
exist in any one of them.
Can you explain why you believe this mechanism, that treats different classes 
differently is the best
way to improve security?

— Ron

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-13 Thread Ron Pressler

> On 13 May 2021, at 10:32, Peter Firmstone  wrote:
> 
> So it targets 17.

I don’t know. I think that’s still TBD, but perhaps others know more.

> 
> It would be nice to have certainty about which release it will be removed 
> from, for planning purposes.   Again it would seem that this isn't a 
> consideration of OpenJDK.

It very much is, which is why we have the deprecation and removal policy. Please
read the JEP carefully. In addition to deprecation and removal, this JEP also 
proposes
an interim step of degradation prior to removal. Removal, as the JEP says, will 
only 
be done once it no longer poses a big compatibility threat. At the fastest pace 
possible
removal is more than a year away, though it will likely be longer than that.

> 
> Is there an OpenJDK community project group that maintains older Java 
> versions I can join?
> 

Yes, that would be the Updates Project.

— Ron

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-13 Thread Peter Firmstone


So it targets 17.

Java 8 has planned support to 2030, longer than 17, it seems unlikely 
the SecurityManager will still be present in an LTS release later than 
17, given that 11 was the last, maybe 23 will be the next LTS version.  
Of course these aren't OpenJDK considerations, maybe someone will decide 
to support a version of Java that has it longer, or maybe they wont.


It would be nice to have certainty about which release it will be 
removed from, for planning purposes.   Again it would seem that this 
isn't a consideration of OpenJDK.


Is there an OpenJDK community project group that maintains older Java 
versions I can join?


Regards,

Peter.


On 13/05/2021 6:21 pm, Ron Pressler wrote:

Whatever version JEP 411 targets, it will *not* remove the Security Manager. 
Even
if 411 targets 17, the Security Manager will still be in 17, precisely because
of the deprecation policy intended to give people time to adjust.

— Ron



On 13 May 2021, at 01:44, Peter Firmstone  wrote:

Ron,

Can JEP 411 be targeted against Java 18 please?

I realize long term support is not OpenJDK's concern, however other's are 
planning Java 17 to be a long term support release and that will impact us.

Thank you,

Peter Firmstone
Zeus Project Services Pty Ltd.

On 13/05/2021 7:43 am, Ron Pressler wrote:

On 8 May 2021, at 05:55, Peter Firmstone  wrote:

What would help in future:

• Define a core Java api, a javadoc annotation? If parts of it are 
deprecated, they will not be removed for eg 3 LTS releases, pick a number, it 
provides certainty.  Developers writing new software then know if they use this 
api, they will not be harmed by breaking changes for x years.
• Removal of api from java.* or javax.* are breaking changes.  This is 
worse than a library breakage, as we can write a compatibility layer for a 
library.   In my own software I provide a compatibility library for older 
versions of software written for Jini, it just decorates old api over new as a 
compatibility layer.   For example we could write a compatibility layer for 
AccessController and doPrivileged methods, so they still work, without shotgun 
surgery. but we can't do that because it's in Java package namespace.
• An annotation will let us know that we can write programs, without 
risk of incurring potentially significant technical debt.

OpenJDK does not have the concept of LTS, and certainly not of "LTS releases.”
Long-term support is a general term for services that anyone is free to offer 
for any OpenJDK version for
any length of time, and even retroactively. You can choose to provide LTS to 
JDK 10 tomorrow if you like.

OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its goal 
is to do exactly what
you describe, and that policy is in effect for this JEP as it is for all other 
similar ones.

But please read JEP 411 carefully. It does give you time; it does talk of a 
gradual process.




• Sun always gave us plenty of time to remove usages of deprecated 
methods, it always took years to clean these up, but there are compiler 
warnings etc.  My point is, we always got them removed eventually, meanwhile we 
were also able to take advantage of new features.

This is the second time you’ve brought up Sun, as if it’s some disjoint group 
of people. People might
have decided to change their policies due to changing circumstances, and the 
circumstances 15 years
ago were certainly no identical to today.



It appears to me that stack walking, which you singled out as a performance 
problem (it isn't), is likely causing difficulties for another project you're 
working on, which is why you are strongly motivated to see it removed.

We would like to see it removed because we believe that the total good the 
Security Manager does the
Java community as a whole does not appear to justify its high cost. In other 
words, we’d like to see it
removed because we believe doing so would do more good for more people than not 
removing it.


This will inflict pain on many projects, I just can't see people upgrading 
their software.  Who's going to pay for all the hours of programming to convert 
perfectly good running code to a new api, just to upgrade to a newer version of 
Java?

Removing stuff absolutely causes pain. We know that, we sympathise, and we’re 
trying to minimise it.
But you have to understand that *not* removing stuff also causes pain, and not 
diverting resources
elsewhere might dissuade other people from using Java because *their* needs 
aren’t addressed. We would
have loved to please everyone but it’s impossible, so we have to make 
decisions, and whatever decision
we make, someone will experience pain in the form of more work they have to do. 
We have to consider the
total pain vs. total good over the entire Java ecosystem. Please also 
understand our perspective: you’re
asking us to pay for hours of work to maintain something that few use, hours 
that could go into work more
people could

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-13 Thread Ron Pressler

Whatever version JEP 411 targets, it will *not* remove the Security Manager. 
Even
if 411 targets 17, the Security Manager will still be in 17, precisely because
of the deprecation policy intended to give people time to adjust.

— Ron


> On 13 May 2021, at 01:44, Peter Firmstone  wrote:
> 
> Ron,
> 
> Can JEP 411 be targeted against Java 18 please?
> 
> I realize long term support is not OpenJDK's concern, however other's are 
> planning Java 17 to be a long term support release and that will impact us.
> 
> Thank you,
> 
> Peter Firmstone
> Zeus Project Services Pty Ltd.
> 
> On 13/05/2021 7:43 am, Ron Pressler wrote:
>> 
>>> On 8 May 2021, at 05:55, Peter Firmstone  
>>> wrote:
>>> 
>>> What would help in future:
>>> 
>>> • Define a core Java api, a javadoc annotation? If parts of it are 
>>> deprecated, they will not be removed for eg 3 LTS releases, pick a number, 
>>> it provides certainty.  Developers writing new software then know if they 
>>> use this api, they will not be harmed by breaking changes for x years.
>>> • Removal of api from java.* or javax.* are breaking changes.  This is 
>>> worse than a library breakage, as we can write a compatibility layer for a 
>>> library.   In my own software I provide a compatibility library for older 
>>> versions of software written for Jini, it just decorates old api over new 
>>> as a compatibility layer.   For example we could write a compatibility 
>>> layer for AccessController and doPrivileged methods, so they still work, 
>>> without shotgun surgery. but we can't do that because it's in Java package 
>>> namespace.
>>> • An annotation will let us know that we can write programs, without 
>>> risk of incurring potentially significant technical debt.
>> OpenJDK does not have the concept of LTS, and certainly not of "LTS 
>> releases.”
>> Long-term support is a general term for services that anyone is free to 
>> offer for any OpenJDK version for
>> any length of time, and even retroactively. You can choose to provide LTS to 
>> JDK 10 tomorrow if you like.
>> 
>> OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its 
>> goal is to do exactly what
>> you describe, and that policy is in effect for this JEP as it is for all 
>> other similar ones.
>> 
>> But please read JEP 411 carefully. It does give you time; it does talk of a 
>> gradual process.
>> 
>> 
>> 
>>> • Sun always gave us plenty of time to remove usages of deprecated 
>>> methods, it always took years to clean these up, but there are compiler 
>>> warnings etc.  My point is, we always got them removed eventually, 
>>> meanwhile we were also able to take advantage of new features.
>> This is the second time you’ve brought up Sun, as if it’s some disjoint 
>> group of people. People might
>> have decided to change their policies due to changing circumstances, and the 
>> circumstances 15 years
>> ago were certainly no identical to today.
>> 
>> 
>>> It appears to me that stack walking, which you singled out as a performance 
>>> problem (it isn't), is likely causing difficulties for another project 
>>> you're working on, which is why you are strongly motivated to see it 
>>> removed.
>> We would like to see it removed because we believe that the total good the 
>> Security Manager does the
>> Java community as a whole does not appear to justify its high cost. In other 
>> words, we’d like to see it
>> removed because we believe doing so would do more good for more people than 
>> not removing it.
>> 
>>> This will inflict pain on many projects, I just can't see people upgrading 
>>> their software.  Who's going to pay for all the hours of programming to 
>>> convert perfectly good running code to a new api, just to upgrade to a 
>>> newer version of Java?
>> Removing stuff absolutely causes pain. We know that, we sympathise, and 
>> we’re trying to minimise it.
>> But you have to understand that *not* removing stuff also causes pain, and 
>> not diverting resources
>> elsewhere might dissuade other people from using Java because *their* needs 
>> aren’t addressed. We would
>> have loved to please everyone but it’s impossible, so we have to make 
>> decisions, and whatever decision
>> we make, someone will experience pain in the form of more work they have to 
>> do. We have to consider the
>> total pain vs. total good over the entire Java ecosystem. Please also 
>> understand our perspective: you’re
>> asking us to pay for hours of work to maintain something that few use, hours 
>> that could go into work more
>> people could enjoy.
>> 
>> — Ron
>

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-13 Thread Peter Tribble

On Wed, May 12, 2021 at 10:49 PM Ron Pressler 
wrote:

>
> > On 12 May 2021, at 22:41, Peter Tribble  wrote:
> >
> > Let me give a concrete example:
> >
> > Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> > We know exactly where the files are installed, so wish to allow the
> rendering routine access
> > to the fonts it will need. But not to any other files, and not
> (normally) to network resources at
> > all. Note that we trust the code, but not necessarily the document it's
> parsing. (Although the
> > document itself may be perfectly well formed - document formats often
> allow embedding
> > references to 3rd-party objects, undesirable as that may be.)
> >
>
> Thank you. Let me ask you this, then:
>
> 1. Would allowing access to certain files and no network for the *entire*
> application be
> sufficient? Consider that you can run some code in a separate Java process
> with OS protections.
> If not, why not?
>

Unfortunately not. We're already running this in a separate sandboxed Java
process to provide a
basic level of isolation. But that process has to interact with the outside
world - it has to get the
file in the first place, and put the result somewhere (which may be to a
filesystem or to a networked
system such as S3). Generally, the permitted level of access will vary
depending on where we are
in the rendering process.

> 2. Would turning such access on and off for the entire application through
> some Java process
> be sufficient?
>

That's effectively what we're doing right now. Essentially we do:

doRender() {
  installSecurityManager();
  do3rdPartyRender();
  uninstallSecurityManager();
}

which is fine because we are in a dedicated sandbox and can be sure that we
aren't doing anything else
at the time.

> 3. Would controlling such access on a per-thread basis be sufficient?
>

In a way, that would be more flexible, as we wouldn't need the
stop-the-world blanket restriction.
It does, however, rely on the assumption that once you've applied the
restriction to a thread then
the do3rdPartyRender() and anything it calls is also restricted to that
thread.

In our specific use case, because we have separate processes already, we
would probably aim for 2
rather than 3. But I can certainly see why 3 is attractive in general - it
allows you to tie a restriction to
a given execution context.

> Please don’t read 2 or 3 as some concrete proposals; I’m just trying to
> understand the requirements.
>
> — Ron
>
>
Thanks,

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-12 Thread David Black

Hi,
I hope it is okay if I provide another
example/use case & view here.

On Thu, 13 May 2021 at 07:49, Ron Pressler  wrote:

>
>
> > On 12 May 2021, at 22:41, Peter Tribble  wrote:
> >
> >
> > Let me give a concrete example:
> >
> > Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> > We know exactly where the files are installed, so wish to allow the
> rendering routine access
> > to the fonts it will need. But not to any other files, and not
> (normally) to network resources at
> > all. Note that we trust the code, but not necessarily the document it's
> parsing. (Although the
> > document itself may be perfectly well formed - document formats often
> allow embedding
> > references to 3rd-party objects, undesirable as that may be.)
> >
>
> Thank you. Let me ask you this, then:
>
> 1. Would allowing access to certain files and no network for the *entire*
> application be
> sufficient? Consider that you can run some code in a separate Java process
> with OS protections.
> If not, why not?
>

It wouldn't be ideal but that is theoretically possible, but that will
likely come at a performance cost & require re-architecting applications.


>
> 2. Would turning such access on and off for the entire application through
> some Java process
> be sufficient?
>

No as this is similar to 1.


>
> 3. Would controlling such access on a per-thread basis be sufficient?
>
> Please don’t read 2 or 3 as some concrete proposals; I’m just trying to
> understand the requirements.
>
>
This seems somewhat more useful than 1 & 2 but imho it would be better to
be able to perform checks/grant access on a call stack basis. Atlassian
currently makes use of a security manager to prevent access to cloud
metadata services that do not have an amazon sdk related class on the call
stack. This helps to mitigate the impact of SSRF in applications running in
a cloud environment (
https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager
).

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-12 Thread Peter Firmstone


Ron,

Can JEP 411 be targeted against Java 18 please?

I realize long term support is not OpenJDK's concern, however other's 
are planning Java 17 to be a long term support release and that will 
impact us.


Thank you,

Peter Firmstone
Zeus Project Services Pty Ltd.

On 13/05/2021 7:43 am, Ron Pressler wrote:



On 8 May 2021, at 05:55, Peter Firmstone  wrote:

What would help in future:

• Define a core Java api, a javadoc annotation? If parts of it are 
deprecated, they will not be removed for eg 3 LTS releases, pick a number, it 
provides certainty.  Developers writing new software then know if they use this 
api, they will not be harmed by breaking changes for x years.
• Removal of api from java.* or javax.* are breaking changes.  This is 
worse than a library breakage, as we can write a compatibility layer for a 
library.   In my own software I provide a compatibility library for older 
versions of software written for Jini, it just decorates old api over new as a 
compatibility layer.   For example we could write a compatibility layer for 
AccessController and doPrivileged methods, so they still work, without shotgun 
surgery. but we can't do that because it's in Java package namespace.
• An annotation will let us know that we can write programs, without 
risk of incurring potentially significant technical debt.

OpenJDK does not have the concept of LTS, and certainly not of "LTS releases.”
Long-term support is a general term for services that anyone is free to offer 
for any OpenJDK version for
any length of time, and even retroactively. You can choose to provide LTS to 
JDK 10 tomorrow if you like.

OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its goal 
is to do exactly what
you describe, and that policy is in effect for this JEP as it is for all other 
similar ones.

But please read JEP 411 carefully. It does give you time; it does talk of a 
gradual process.




• Sun always gave us plenty of time to remove usages of deprecated 
methods, it always took years to clean these up, but there are compiler 
warnings etc.  My point is, we always got them removed eventually, meanwhile we 
were also able to take advantage of new features.

This is the second time you’ve brought up Sun, as if it’s some disjoint group 
of people. People might
have decided to change their policies due to changing circumstances, and the 
circumstances 15 years
ago were certainly no identical to today.



It appears to me that stack walking, which you singled out as a performance 
problem (it isn't), is likely causing difficulties for another project you're 
working on, which is why you are strongly motivated to see it removed.

We would like to see it removed because we believe that the total good the 
Security Manager does the
Java community as a whole does not appear to justify its high cost. In other 
words, we’d like to see it
removed because we believe doing so would do more good for more people than not 
removing it.


This will inflict pain on many projects, I just can't see people upgrading 
their software.  Who's going to pay for all the hours of programming to convert 
perfectly good running code to a new api, just to upgrade to a newer version of 
Java?

Removing stuff absolutely causes pain. We know that, we sympathise, and we’re 
trying to minimise it.
But you have to understand that *not* removing stuff also causes pain, and not 
diverting resources
elsewhere might dissuade other people from using Java because *their* needs 
aren’t addressed. We would
have loved to please everyone but it’s impossible, so we have to make 
decisions, and whatever decision
we make, someone will experience pain in the form of more work they have to do. 
We have to consider the
total pain vs. total good over the entire Java ecosystem. Please also 
understand our perspective: you’re
asking us to pay for hours of work to maintain something that few use, hours 
that could go into work more
people could enjoy.

— Ron

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

P.S.

Sorry, I just realised I used the word “process” in 1 and 2 with different 
meanings. In 1 I meant an 
OS process running Java; in 2 I merely meant a Java mechanism (as opposed to an 
OS mechanism).

> On 12 May 2021, at 22:49, Ron Pressler  wrote:
> 
> 
> 
>> On 12 May 2021, at 22:41, Peter Tribble  wrote:
>> 
>> 
>> Let me give a concrete example:
>> 
>> Parsing and rendering a PDF file that may contain references to fonts or 
>> other resources.
>> We know exactly where the files are installed, so wish to allow the 
>> rendering routine access
>> to the fonts it will need. But not to any other files, and not (normally) to 
>> network resources at
>> all. Note that we trust the code, but not necessarily the document it's 
>> parsing. (Although the
>> document itself may be perfectly well formed - document formats often allow 
>> embedding
>> references to 3rd-party objects, undesirable as that may be.)
>> 
> 
> Thank you. Let me ask you this, then:
> 
> 1. Would allowing access to certain files and no network for the *entire* 
> application be
> sufficient? Consider that you can run some code in a separate Java process 
> with OS protections.
> If not, why not?
> 
> 2. Would turning such access on and off for the entire application through 
> some Java process
> be sufficient?
> 
> 3. Would controlling such access on a per-thread basis be sufficient?
> 
> Please don’t read 2 or 3 as some concrete proposals; I’m just trying to 
> understand the requirements.
> 
> — Ron
>

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 12 May 2021, at 22:41, Peter Tribble  wrote:
> 
> 
> Let me give a concrete example:
> 
> Parsing and rendering a PDF file that may contain references to fonts or 
> other resources.
> We know exactly where the files are installed, so wish to allow the rendering 
> routine access
> to the fonts it will need. But not to any other files, and not (normally) to 
> network resources at
> all. Note that we trust the code, but not necessarily the document it's 
> parsing. (Although the
> document itself may be perfectly well formed - document formats often allow 
> embedding
> references to 3rd-party objects, undesirable as that may be.)
> 

Thank you. Let me ask you this, then:

1. Would allowing access to certain files and no network for the *entire* 
application be
sufficient? Consider that you can run some code in a separate Java process with 
OS protections.
If not, why not?

2. Would turning such access on and off for the entire application through some 
Java process
be sufficient?

3. Would controlling such access on a per-thread basis be sufficient?

Please don’t read 2 or 3 as some concrete proposals; I’m just trying to 
understand the requirements.

— Ron

Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 8 May 2021, at 05:55, Peter Firmstone  wrote:
> 
> What would help in future:
> 
>   • Define a core Java api, a javadoc annotation? If parts of it are 
> deprecated, they will not be removed for eg 3 LTS releases, pick a number, it 
> provides certainty.  Developers writing new software then know if they use 
> this api, they will not be harmed by breaking changes for x years.
>   • Removal of api from java.* or javax.* are breaking changes.  This is 
> worse than a library breakage, as we can write a compatibility layer for a 
> library.   In my own software I provide a compatibility library for older 
> versions of software written for Jini, it just decorates old api over new as 
> a compatibility layer.   For example we could write a compatibility layer for 
> AccessController and doPrivileged methods, so they still work, without 
> shotgun surgery. but we can't do that because it's in Java package namespace.
>   • An annotation will let us know that we can write programs, without 
> risk of incurring potentially significant technical debt.

OpenJDK does not have the concept of LTS, and certainly not of "LTS releases.” 
Long-term support is a general term for services that anyone is free to offer 
for any OpenJDK version for 
any length of time, and even retroactively. You can choose to provide LTS to 
JDK 10 tomorrow if you like.

OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its goal 
is to do exactly what 
you describe, and that policy is in effect for this JEP as it is for all other 
similar ones.

But please read JEP 411 carefully. It does give you time; it does talk of a 
gradual process.

>   • Sun always gave us plenty of time to remove usages of deprecated 
> methods, it always took years to clean these up, but there are compiler 
> warnings etc.  My point is, we always got them removed eventually, meanwhile 
> we were also able to take advantage of new features.

This is the second time you’ve brought up Sun, as if it’s some disjoint group 
of people. People might 
have decided to change their policies due to changing circumstances, and the 
circumstances 15 years 
ago were certainly no identical to today.

> 
> It appears to me that stack walking, which you singled out as a performance 
> problem (it isn't), is likely causing difficulties for another project you're 
> working on, which is why you are strongly motivated to see it removed.

We would like to see it removed because we believe that the total good the 
Security Manager does the 
Java community as a whole does not appear to justify its high cost. In other 
words, we’d like to see it 
removed because we believe doing so would do more good for more people than not 
removing it.

> 
> This will inflict pain on many projects, I just can't see people upgrading 
> their software.  Who's going to pay for all the hours of programming to 
> convert perfectly good running code to a new api, just to upgrade to a newer 
> version of Java?

Removing stuff absolutely causes pain. We know that, we sympathise, and we’re 
trying to minimise it. 
But you have to understand that *not* removing stuff also causes pain, and not 
diverting resources 
elsewhere might dissuade other people from using Java because *their* needs 
aren’t addressed. We would 
have loved to please everyone but it’s impossible, so we have to make 
decisions, and whatever decision 
we make, someone will experience pain in the form of more work they have to do. 
We have to consider the 
total pain vs. total good over the entire Java ecosystem. Please also 
understand our perspective: you’re
asking us to pay for hours of work to maintain something that few use, hours 
that could go into work more
people could enjoy.

— Ron

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-12 Thread Peter Tribble

On Wed, May 12, 2021 at 10:22 PM Ron Pressler 
wrote:

>
>
> > On 12 May 2021, at 21:46, Peter Tribble  wrote:
> >
> > We're (partly, at least) in that group. We can't block the access from
> outside
> > the JVM (and we are containerized with restricted permissions already)
> because
> > some accesses are legitimate - something outside the JVM doesn't know
> when
> > the JVM is executing a particular piece of code, so we toggle the
> Security Manager
> > on and off depending on context.
> >
> > And here's the thing; there isn't really anything in the proposal that
> addresses this
> > use case, or offers an alternate way forward.
>
> Could you describe what your use-case is in the most precise way you can?
>

Let me give a concrete example:

Parsing and rendering a PDF file that may contain references to fonts or
other resources.
We know exactly where the files are installed, so wish to allow the
rendering routine access
to the fonts it will need. But not to any other files, and not (normally)
to network resources at
all. Note that we trust the code, but not necessarily the document it's
parsing. (Although the
document itself may be perfectly well formed - document formats often allow
embedding
references to 3rd-party objects, undesirable as that may be.)

There are a range of such issues in document parsing and rendering. And
unfortunately, the
good libraries for this task are proprietary so we can't modify them to
apply the restrictions
we're after. The (server-side) application does need access to files and
network resources at
other times; it's only when it goes into the rendering step that we lock it
down, and unlock it
once done.

> That there are useful applications of the Security Manager out there is
> certain; the same
> was certainly also true for Applets. The problem is that the total good
> that the Security
> Manager contributes does not justify the high cost of its maintenance. The
> more we can
> understand what people use it for and how, the better we are able to judge
> how much we
> should afford to put into some simpler replacement. Having said that, it
> is certainly
> possible that some of the millions of Java developers out there will be
> disappointed. We
> try to direct our resources where they’d do the most good, and when we
> can, try to find
> a solution for small groups that are harmed by such budgeting.
>

I appreciate the reasoning here, and thanks for letting us try and describe
some our
use cases.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Re: JEP411: Missing use-case: Monitoring / restricting libraries

> On 12 May 2021, at 21:46, Peter Tribble  wrote:
> 
> We're (partly, at least) in that group. We can't block the access from outside
> the JVM (and we are containerized with restricted permissions already) because
> some accesses are legitimate - something outside the JVM doesn't know when
> the JVM is executing a particular piece of code, so we toggle the Security 
> Manager
> on and off depending on context.
> 
> And here's the thing; there isn't really anything in the proposal that 
> addresses this
> use case, or offers an alternate way forward.

Could you describe what your use-case is in the most precise way you can?

That there are useful applications of the Security Manager out there is 
certain; the same
was certainly also true for Applets. The problem is that the total good that 
the Security
Manager contributes does not justify the high cost of its maintenance. The more 
we can
understand what people use it for and how, the better we are able to judge how 
much we
should afford to put into some simpler replacement. Having said that, it is 
certainly 
possible that some of the millions of Java developers out there will be 
disappointed. We
try to direct our resources where they’d do the most good, and when we can, try 
to find
a solution for small groups that are harmed by such budgeting.

— Ron

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-12 Thread Peter Tribble

On Thu, May 6, 2021 at 12:48 PM Alan Bateman 
wrote:

> On 06/05/2021 11:26, Peter Firmstone wrote:
> >
> > OpenJDK seems to have assumed that no one was using SecurityManager
> > based on one research report.
> >
> I don't think this is right. Instead I would say that many of us have
> rarely encountered deployments on the server-side that are using a
> SecurityManager to enforce security as envisaged by the Java security
> model. I've been at Java conferences where the sessions on this topic
> had less than 10 people in the room. Most of the actual usages that I've
> come across have been more like using the security manager as a
> convenient way to intercept network and file access for the purposes of
> logging or blocking. These usages may not have a need for protection
> domains, stack walks, policy files and the other complexity that comes
> with the security model.
>

We're (partly, at least) in that group. We can't block the access from
outside
the JVM (and we are containerized with restricted permissions already)
because
some accesses are legitimate - something outside the JVM doesn't know when
the JVM is executing a particular piece of code, so we toggle the Security
Manager
on and off depending on context.

And here's the thing; there isn't really anything in the proposal that
addresses this
use case, or offers an alternate way forward.

> One thing that is missing from the discussions here is the cost and tax
> that supporting the SM "operating mode" brings. Many of the big features
> and all changes to security sensitive code must pay this tax. If there
> is a bug, a missing checkPermission for example, then it gets treated as
> security vulnerability at massive cost. Everything asynchronous brings
> more complexity and effort to figure out where the checks should be and
> whether an AccessControlContext needs to be carried around. I look
> forward to the day where we can be like other languages and runtimes
> that don't have to be concerned with this complexity and optional way of
> running.
>
> Finally, just to point out again that this JEP is about deprecating for
> removal in the future, it doesn't propose to remove the security manager
> now. If it moves forward then it will probably be several releases of
> degradation before it is removed. That gives time to properly consider
> the use cases where the security manager is useful today. Also if it is
> eventually removed, then anyone that really depends on this world can
> continue to use supported releases for years to come.
>

I appreciate that there will be older versions we can run; the issue is
always
that there may be some external driver why we have to update - either to
gain
a critical feature, or because something else doesn't support the old
version.

I know I would feel a lot happier with this proposal and its implications
if the
consideration of those use cases where the security manager is useful today
was more fully fleshed out.

Thanks,

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-08 Thread Peter Firmstone


Ron,

Thanks for the discussion.  Although we have different opinions, I do 
appreciate that you took the time to reply.


--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries



On 7/05/2021 1:17 pm, Peter Firmstone wrote:


On 6/05/2021 9:46 pm, Ron Pressler wrote:
That is correct. Here is where this is mentioned for ForkJoinPool: 
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/concurrent/ForkJoinPool.html 



And here it is for virtual threads (the JavaDoc is still a WIP):
https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Thread.html#startVirtualThread(java.lang.Runnable) 




Can I use doPrivileged blocks with context, or will they be 
innefective?  If yes to the former and no to the latter, then it's 
great these threads have no permission by default.


Just trying to work out if I can use it with secure network connections? 


--
Regards,
 
Peter

Re: JEP411: Missing use-case: Monitoring / restricting libraries


What would help in future:

1. Define a core Java api, a javadoc annotation? If parts of it are
   deprecated, they will not be removed for eg 3 LTS releases, pick a
   number, it provides certainty.  Developers writing new software then
   know if they use this api, they will not be harmed by breaking
   changes for x years.
2. Removal of api from java.* or javax.* are breaking changes. This is
   worse than a library breakage, as we can write a compatibility layer
   for a library.   In my own software I provide a compatibility
   library for older versions of software written for Jini, it just
   decorates old api over new as a compatibility layer.   For example
   we could write a compatibility layer for AccessController and
   doPrivileged methods, so they still work, without shotgun surgery.
   but we can't do that because it's in Java package namespace.
3. An annotation will let us know that we can write programs, without
   risk of incurring potentially significant technical debt.
4. Sun always gave us plenty of time to remove usages of deprecated
   methods, it always took years to clean these up, but there are
   compiler warnings etc.  My point is, we always got them removed
   eventually, meanwhile we were also able to take advantage of new
   features.

If OpenJDK does that, then I personally would continue use of Java for 
new projects.


OpenJDK is not doing anything to ease the pain of migration, when you 
could do better.


I'm curious, what are other developers using instead of Subject.doAs, 
JAAS and AccessController.doPrivileged to authenticate TLS connections?


In JGDMS I found:

916 matches of AccessController in 264 files, and that's excluding tests.

515 matches of AccessControlContext in 121 files, again excluding tests.

It appears to me that stack walking, which you singled out as a 
performance problem (it isn't), is likely causing difficulties for 
another project you're working on, which is why you are strongly 
motivated to see it removed.


This isn't like other API's that are being removed, so far we have only 
been impacted in parts of our codebase.


This will inflict pain on many projects, I just can't see people 
upgrading their software.  Who's going to pay for all the hours of 
programming to convert perfectly good running code to a new api, just to 
upgrade to a newer version of Java?


Just can't see it happening.

--
Regards,
 
Peter


On 8/05/2021 8:42 am, Ron Pressler wrote:

Many of the people who worked at Sun still work at Oracle on Java today, and 
that group includes all the people who
signed their names on this JEP, but Java today has ten more years of baggage to 
maintain than it did back then. The
speed at which things are removed after deprecation is meant to be 
proportionate to their level of use.

I believe that, despite the fact that some less used things are, indeed, being 
removed now while they weren’t before,
Java still compares favourable with many other languages/platforms as far as 
stability and compatibility is concerned.
I think that saying that “move fast and break things” is the new philosophy is 
not only unfair, but very, very far
from the truth.

— Ron



On 7 May 2021, at 23:20, Peter Firmstone  wrote:


On 8/05/2021 4:21 am, Ron Pressler wrote:

Deprecation/removal JEPs, and this one is no exception, make the following 
claim: that the total good a certain JDK capability
currently contributes to the Java ecosystem at large does not justify the cost 
of its maintenance, and it should, therefore, be
removed — gradually, of course, and with enough time for users to find 
alternatives. An argument against such a JEP would take
the form of, no, the total good the feature contributes to the ecosystem does 
justify its cost.


Sun Microsystems would deprecate, but were very slow to remove API that caused 
breakages, they were also very considerate about how they would modify api in a 
backward compatible manner. OpenJDK has already demonstrated it removes api 
very quickly after deprecation.  OpenJDK has adopted the move quickly and break 
things philosophy.

I really like the new language features under development, but the continual 
breakages are causing me to rethink.

I still haven't worked out how to replace some of the more recently removed 
features, we are still building on Java 8, because of missing components in 
Java 11, although we use features from and test on later versions.  We haven't 
been testing on Java 8, because our default ciphers target the most recent 
versions and we disable anything less by default.

Other breaking changes that have been removed can be replaced by library code, 
but cause breakages since we are unable to use the java.* package namespace.  
It would be friendlier, if OpenJDK allowed libraries to be developed 
separately, using the java.* namespace, perhaps as part of the project.

This core platform feature that will be removed, probably after Java 17, but 
before the following long term support

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-07 Thread Ron Pressler

Many of the people who worked at Sun still work at Oracle on Java today, and 
that group includes all the people who 
signed their names on this JEP, but Java today has ten more years of baggage to 
maintain than it did back then. The 
speed at which things are removed after deprecation is meant to be 
proportionate to their level of use.

I believe that, despite the fact that some less used things are, indeed, being 
removed now while they weren’t before,
Java still compares favourable with many other languages/platforms as far as 
stability and compatibility is concerned.
I think that saying that “move fast and break things” is the new philosophy is 
not only unfair, but very, very far
from the truth.

— Ron


> On 7 May 2021, at 23:20, Peter Firmstone  wrote:
> 
> 
> On 8/05/2021 4:21 am, Ron Pressler wrote:
>> Deprecation/removal JEPs, and this one is no exception, make the following 
>> claim: that the total good a certain JDK capability
>> currently contributes to the Java ecosystem at large does not justify the 
>> cost of its maintenance, and it should, therefore, be
>> removed — gradually, of course, and with enough time for users to find 
>> alternatives. An argument against such a JEP would take
>> the form of, no, the total good the feature contributes to the ecosystem 
>> does justify its cost.
>> 
> Sun Microsystems would deprecate, but were very slow to remove API that 
> caused breakages, they were also very considerate about how they would modify 
> api in a backward compatible manner. OpenJDK has already demonstrated it 
> removes api very quickly after deprecation.  OpenJDK has adopted the move 
> quickly and break things philosophy.
> 
> I really like the new language features under development, but the continual 
> breakages are causing me to rethink.
> 
> I still haven't worked out how to replace some of the more recently removed 
> features, we are still building on Java 8, because of missing components in 
> Java 11, although we use features from and test on later versions.  We 
> haven't been testing on Java 8, because our default ciphers target the most 
> recent versions and we disable anything less by default.
> 
> Other breaking changes that have been removed can be replaced by library 
> code, but cause breakages since we are unable to use the java.* package 
> namespace.  It would be friendlier, if OpenJDK allowed libraries to be 
> developed separately, using the java.* namespace, perhaps as part of the 
> project.
> 
> This core platform feature that will be removed, probably after Java 17, but 
> before the following long term support version cannot be replaced by a 
> library.
> 
> The maintenance debt is building up too fast to keep up with.
> 
> I can't justify writing new projects in Java until the API has stabilized, 
> it's fair to say the new API is Java like, but C# is also Java like, as is 
> Android.
> 
> It's clear OpenJDK wants Java to be like younger languages, and since that's 
> where it's headed, I might as well select one of those instead, what kept me 
> developing on Java was its stability and performance, when newer languages 
> could do the same with less.  Performance of newer languages will improve 
> with time, just like Java did and their API's will become more stable.
> 
> -- 
> Regards,
> Peter Firmstone
> Zeus Project Services Pty Ltd.
>

Re: JEP411: Missing use-case: Monitoring / restricting libraries




On 8/05/2021 4:21 am, Ron Pressler wrote:

Deprecation/removal JEPs, and this one is no exception, make the following 
claim: that the total good a certain JDK capability
currently contributes to the Java ecosystem at large does not justify the cost 
of its maintenance, and it should, therefore, be
removed — gradually, of course, and with enough time for users to find 
alternatives. An argument against such a JEP would take
the form of, no, the total good the feature contributes to the ecosystem does 
justify its cost.

Sun Microsystems would deprecate, but were very slow to remove API that 
caused breakages, they were also very considerate about how they would 
modify api in a backward compatible manner. OpenJDK has already 
demonstrated it removes api very quickly after deprecation.  OpenJDK has 
adopted the move quickly and break things philosophy.


I really like the new language features under development, but the 
continual breakages are causing me to rethink.


I still haven't worked out how to replace some of the more recently 
removed features, we are still building on Java 8, because of missing 
components in Java 11, although we use features from and test on later 
versions.  We haven't been testing on Java 8, because our default 
ciphers target the most recent versions and we disable anything less by 
default.


Other breaking changes that have been removed can be replaced by library 
code, but cause breakages since we are unable to use the java.* package 
namespace.  It would be friendlier, if OpenJDK allowed libraries to be 
developed separately, using the java.* namespace, perhaps as part of the 
project.


This core platform feature that will be removed, probably after Java 17, 
but before the following long term support version cannot be replaced by 
a library.


The maintenance debt is building up too fast to keep up with.

I can't justify writing new projects in Java until the API has 
stabilized, it's fair to say the new API is Java like, but C# is also 
Java like, as is Android.


It's clear OpenJDK wants Java to be like younger languages, and since 
that's where it's headed, I might as well select one of those instead, 
what kept me developing on Java was its stability and performance, when 
newer languages could do the same with less.  Performance of newer 
languages will improve with time, just like Java did and their API's 
will become more stable.


--
Regards,
 
Peter Firmstone

Zeus Project Services Pty Ltd.

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-07 Thread Ron Pressler

Deprecation/removal JEPs, and this one is no exception, make the following 
claim: that the total good a certain JDK capability 
currently contributes to the Java ecosystem at large does not justify the cost 
of its maintenance, and it should, therefore, be 
removed — gradually, of course, and with enough time for users to find 
alternatives. An argument against such a JEP would take 
the form of, no, the total good the feature contributes to the ecosystem does 
justify its cost.

But that is not the argument you are making. Instead, you are proposing a 
rethinking of the Security Manager. This is similar,
and, I would say, identical, to proposing a new Project, which is judged by its 
*expected* merit vs. its expected cost. But
that is a very different discussion. Obviously, arguing in favour of a new 
Project to redesign and re-market a feature that
has been tried for over two decades and has failed to yield the expected good 
in recent years (possibly due to changing 
circumstances) would require a very compelling argument, and might be a tough 
sell, but in any event, this is not what is being 
discussed in this particular context. I could agree with some, most, or even 
all of your points, and yet I don’t think they
are relevant to the central claim made by JEP 411.

I also sense, from things you’ve said and also from reading between the lines, 
that you might be interpreting certain legal
limitations in a manner that might be stricter than required. I am not 
qualified to give any legal advice and I would not
attempt to do so, but I would like to point out that the JDK classes are 
distributed under a well-known open-source
license with well-known terms, and the question of their use is separate from 
the question of introducing *new* classes that
make use of certain trademarked names. I don't know where you can obtain advice 
on such matters.

— Ron

> On 7 May 2021, at 11:17, Peter Firmstone  wrote:
> 
> 
> On 6/05/2021 9:46 pm, Ron Pressler wrote:
>> 
>> Trying to convince people, at this point, after twenty five years that the 
>> Security Manager isn’t complicated after all might
>> be too little too late.
> 
> 
> Static policy, terrible performance, no scalability at all, and the fact that 
> you continually have to edit policy files manually, and there's no auditing 
> tools?
> 
> Ha ha ha. :)  It's complicated, ha ha ha, it hardly works!  Why would a 
> developer spend time writing concurrent code, then turn on security and slow 
> their hard work to a crawl?  That's why they simplify it and bypass the 
> policy.
> 
> No, complexity is not the problem.
> 
> It was a good design for 1997, but the java code it's written in is also from 
> 1997 with little maintenance since.
> 
> For shame.
> 
> From my observations, the native code in AccessController is scalable and 
> performant and has little overhead, someone has done some very good work 
> there, that has to be more recent.   This is a very good piece of work, very 
> good indeed.
> 
> Sorry, I had to point out some truths.
> 
> My static policy (as stated previously there is a dynamic policy also) is a 
> direct drop in replacement, you could ship with that, it would be a start.  
> You could even remove the Java policy implementation and I can make my policy 
> implementation available on Maven.  It's AL2.0 licensed, I did look at 
> donating it some time ago.   The code has provenance, I'm not the sole 
> author, I can only donate parts of it under GPL2.0
> 
> I can also donate the profiling tool.
> 
> The thing is, if it was performant, people would stop switching it off, and 
> if there were tools to handle policy complexity, then they will start using 
> it, they have to use it for Principal permissions.
> 
> Here's what OSGi does, they associate permissions with modules, to reduce 
> complexity:
> 
> https://urldefense.com/v3/__https://docs.osgi.org/specification/osgi.core/8.0.0/service.condpermadmin.html__;!!GqivPVa7Brio!MA0LQDajtSBzAF17g-T_xjcu0qI1jv040zIzdYPlJ2ZRrM9RxvFl4ZxZc8leWZNQYw$
>  
> -- 
> Regards,
> Peter Firmstone
> Zeus Project Services Pty Ltd.
>

Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-07 Thread Will Sargent

You may be interested in tweakflow [1] in that case -- it's a scripting
language that doesn't allow arbitrary operations (as opposed to Groovy etc)
and can even limit the execution time [2]

I would probably not set up a security manager to monitor operations, as
any situation which called for a security manager could be targeted more
precisely using a Java agent running Byte Buddy to do interception. [3]

[1] https://twineworks.github.io/tweakflow/index.html
[2]
https://twineworks.github.io/tweakflow/embedding.html#limiting-evaluation-time
[3] https://tersesystems.github.io/terse-logback/guide/instrumentation/

On Sat, Apr 17, 2021 at 1:24 AM Anthony Vanelverdinghe 
wrote:

> Actually I think GraalVM can already do this today, since the mentioned
> API is for use with any guest language, and Java can now run as a guest
> language [1]. Note that this is also reminiscent of the `java.scripting`
> module (JSR 223), which also has a `ScriptContext` class, but I'm not sure
> what the long-term plans are for that API.
>
> Imho, any new mechanism should be tightly integrated with the module
> system. In fact, Panama already has the concept of "restricted operations".
> Currently, access to these operations is enabled with a simple system
> property, but, quoting from [2]:
> > We plan, in the future, to make access to restricted operations more
> integrated with the module system; that is, certain modules might require
> restricted native access; when an application which depends on said modules
> is executed, the user might need to provide permissions to said modules to
> perform restricted native operations, or the runtime will refuse to build
> the application's module graph.
>
> Kind regards, Anthony
>
> [1] https://github.com/oracle/graal/tree/master/espresso
> [2]
> https://htmlpreview.github.io/?https://github.com/openjdk/panama-foreign/blob/eb2f956aef1d039a0d364eb69ed91bb9293c4387/doc/panama_memaccess.html
>
> On Friday, April 16, 2021 23:37 CEST, Mark Raynsford 
> wrote:
>
> > On 2021-04-16T17:02:06 -0400
> > Sean Mullan  wrote:
> > >
> > > That said, I think it is worth exploring (in this JEP) or another JEP
> > > ways that we might think about that could help provide DiD protection
> > > for network and file access. This is an opportunity to look at the
> > > problem with a fresh set of eyes, w/o the existing complicated
> > > infrastructure and APIs that encompass the Security Manager.
> >
> > This is something that has interested me in the past. Although I'm not
> > working on anything currently that would need it, I've often come up
> > against this sort of thing in application plugin systems. That is,
> > users have an application that they do trust and they want to load
> > plugins into it that weren't written by the application author and that
> > they do not necessarily trust.
> >
> > Languages such as Lua handle this fairly well by having programmers
> > create lightweight scripting contexts for running scripts inside a
> > host program. The guest scripts:
> >
> >   * Can't call I/O methods if they aren't given access to a
> > a table of I/O methods. This actually extends to not being
> > able to call foreign code at all if access isn't provided;
> > scripts are limited to objects within the provided table.
> >
> >   * Can't use unbounded heap space if a custom allocator is
> > handed to the script context.
> >
> >   * Can't go into an infinite loop if instruction count limits
> > are enabled (the interpreter is pre-empted or halted if it
> > reaches N instructions, where N is some value configured
> > by the host).
> >
> >   * Can't create new threads.
> >
> >   * Are probably memory-safe, assuming a lack of bugs in the
> > Lua interpreter. :)
> >
> > Under those constraints, it's pretty tough to do anything disruptive
> > even if you're trying to. Without access to I/O functions and other
> > foreign code in the global table, you're pretty much limited to doing
> > arithmetic. Quietly. And not too much of it.
> >
> > Similar constraints are available for code running under GraalJS [0]
> > and that's certainly achieved without a security manager.
> >
> > I'm more inclined to think something that is rather blunt and brute
> > force can be made to work well than something extremely fine-grained
> > like the security manager. The blunt and brute force method says
> > "put all this small piece of untrusted code in this box, and it's
> > not allowed to do anything other than the very few things I say it can,
> > and the code outside of the box is allowed to do whatever it could
> > normally do". The security manager more or less has to have a large
> > manually-maintained policy for the entire application and everything in
> > it, and I think that's where it falls over.
> >
> > [0]:
> https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Context.Builder.html
> >
> > --
> > Mark Raynsford | https://www.io7m.com
> >
>
>

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries