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

[Ron Pressler]

> On 21 May 2021, at 11:29, Peter Firmstone <peter.firmstone at zeus.net.au> 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