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

Peter Firmstone peter.firmstone at zeus.net.au
Fri May 21 10:29:22 UTC 2021


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





More information about the security-dev mailing list