On 23/07/2021 23:33, Peter Firmstone wrote:
I think it's worth noting that there isn't a way to securely run code
with malicious intent now, so I'm surprised that at this late stage
you were still providing support for sand boxing (whack a mole).
It's just for us many assumptions have been made on a Java platform
with SM, using POLP (not sandboxing) as this was one of the
foundational principles of secure coding guidelines (just like
following concurrency best practice, were were following security best
practice). Sandboxing is an all or nothing approach, if you had a
trusted applet that was signed, it had AllPermission, if you had an
unsigned applet, then it had no permissions. Sandboxing was one of
the use cases for SM, when combined with ClassLoader visibility, but
we never realized that OpenJDK developers meant sandboxing ==
authorization access controls.
When you remove that pillar, everything it's supporting collapses, not
just sand boxing, so when you say you are removing support for
sandboxing, we say, good idea, but we didn't realize you were saying
you were removing support for all authorization access controls.
Reduced and revised authorization and access control would have been
acceptable, as tightening reflection visibility using a different form
of access control removes the need for authorization based reflection
access checks, but also removing atomic construction guarantee's just
seems like were doing this at a rapid pace without the community
understanding what you have in mind, and this may have more uses than
just stopping finalizer attacks.
I'm not 100% sure what you mean by "atomic construction guarantee" here.
This JEP does not propose to change anything with finalization or do
anything with the registration of finalizers after Object.<init> runs.
Our exchange in the previous mails was about classes (using ClassLoader
as the example) that specify a SM permission check in their
constructors, something that is strongly discouraged as the checks are
easy to bypass. The idiom that we use in the JDK to prevent bypassing
these SM permission checks with a finalizer attack is to check in a
static method that returns a dummy parameter for the invokespecial. My
point in the previous mail is that when the SM permission checks
eventually go away then many of the uses of this idiom can do away too.
That said, there is strong desire to eventually remove finalization too.
Finalization was deprecated several years ago and the Java platform
defines APIs that provide much more flexible and efficient ways do run
cleanup actions when an object becomes unreachable. So another
multi-year/multi-release effort to remove a problematic feature, just
nothing to do with this JEP.
As regards POLP, the focus of SM architecture when it was enhanced in
Java 1.2. The JEP attempts to explain why this has been a failure.
AccessController is voodoo that most developers have never encountered
so anyone trying to run with SM ends up running counter to the principle
of least privilege by granting all permissions.
-Alan.
