subject:"\[External\] \: 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 th

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 address,

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, because

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 Se

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

2021-05-17 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, 
 certain

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.
https://urldefense.com/v3/__https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eX

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 T

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 d

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
propos

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 pract

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] 
> https://urldefense.com/v3/__https://square.github.io/okhttp/changelog_3x/*versio

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