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
