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

[Peter Firmstone]

On 21/05/2021 9:14 pm, Ron Pressler wrote:
>
>> 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.


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

This is not new software, these justifications are for new features, and 
would have been originally considered, now it has become a backward 
compatibility and functionality issue, no replacement functionality is 
available.

I don't see how you can argue there are better ways if they don't exist.

This is a breaking change to Java, so after this JEP, you should be 
releasing Java 2.0.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210521/298feed0/attachment.htm>