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. Unfortunately when you develop a feature, you can't
be sure developers won't adapt and utilize it for multiple purposes.
Personally I think a better approach would have been to first reduce and
simplify authorization access controls, replacing some of the
functionality with different but more appropriate mechanisms.
Removing authorization access control features, without replacement
means our software would be insecure, there isn't an obvious way to
re-secure it, without re-architecting or re-designing it from the ground
up, and Java is now a moving target anyway, so we would have to wait for
it to re-stabilize as it transitions from Hippy to Hipster Java (just
making a point it's not the same Java).
With this new understanding, we need to reconsider both the language and
the platform that we'll be developing on. Clearly a language with less
boilerplate is an obvious start, I don't yet know which, we will still
consider the JVM, but it would be with Kafka or Clojure, but then we
also need to consider whether we will be able to secure the underlying
platform, or at least use it securely. Arguably we can do things now
that aren't possible on other platforms, so we need to develop that
capability as well, not just secure it.
Regards,
Peter.
On 23/07/2021 9:45 pm, Alan Bateman wrote:
On 23/07/2021 11:48, Peter Firmstone wrote:
Perhaps the solution is to replace the entire class, instead of
instrumenting one method?
Compile a patched copy of the JVM, with modified class files, then
replace the existing classes in the JVM with the modified classes?
Kinda like maintaining a fork, but using Agents to instrument the
original JVM with classes from the fork?
I sure wish there was a better option, if anyone knows one, I'm all
ears.
JEP 411 puts the JDK on the road to dropping support for sandboxing.
This means there won't be a built-in means to securely run code that
has malicious intent. It means that many of the concerns for finalizer
attacks go away too. In the case of the ClassLoader example in your
first mail then it may be that the private static method that you want
to instrument will be removed. If removed, then it should make the
instrumentation a bit easier so that you can instrument the protected
constructors to invokestatic your equivalent of a permission check
before the invokespecial. So I think this specific case is
surmountable but in general I don't think it will be tenable to patch
hundreds of classes and be confident that you've got everything, esp.
with a moving code base and new features. I can't tell if your
"authorization layer" is for use when running with code that has
malicious intent. If it is, then I don't think it will be tenable to
duplicate all the deeply invasive permission checks that exist today
and keep it up to date as new features and changes. When agents were
muted in the early discussion on JEP 411 then the context was file and
network access where several people were interested in having a means
to veto access. Expanding this to have a SM equivalent be able to veto
every reflective access, prevent trusted method chain and other
attacks, amounts to keeping the SM forever.
As regards the comments about agents having the power to instrument
methods that aren't accessible to user code then that is normal. Java
agents are for tools to do powerful things, they aren't intended for
libraries for applications to use directly. This is why agents are
opt-in on the command line. Agent maintainers weld great power and
must take care to never leak the Instrumentation object to
applications or libraries.
-Alan
