Trusted code only, but it's intended to be run in a locked down
principle of least privilege environment, while we perform static
analysis and targeted review, we don't have the resources required to
perform thorough trusted code audits, so have been reliant on the
principle of least privilege. Hence the ability to generate policy
files that we use for auditing.
I utilize the constructor guarantee added in Java 6, that prevents
finalizer attacks for atomic de-serialization, if invariants aren't
satisfied, failure is atomic, thanks to this feature.
We use the SM to ensure network connections used are secure and only
have authenticated users, otherwise de-serialization and dynamic class
loading is prevented.
We don't need all the SM permission check features, but preventing
unauthorized class loading is one of them. Network, file access, class
loading, properties are a few that come to mind, I'm not worried about
reflection, other recent changes are taking care of reflective access.
We have a heap of our own Permission implementations as well.
It appears that Java's future path is diverging from our software's
needs and Java won't be a suitable platform in future. I wasn't aware
that Java was heading in this direction. JEP 411 came as a big
surprise, it just seemed like it was a core Java feature.
I think the best course of action, will be to focus on Java 8, until
that's EOL'd. I do like the improvements to TLS stateless connections
and new features in later Java versions, but it looks like a mistake to
try and keep up with Java, with this new knowledge. I think I'll back
out some more recent changes that were intended to allow our software to
run on Java 17, as these cause breakages for downstream developers and
it doesn't seem to make much sense now, to make those breaking changes.
I was actually looking forward to taking advantage of loom and the new
vector API, but it looks like I need to be focused on what's going to be
our next software platform. I've always found llvm to be interesting,
so maybe I'll focus on some languages that run on that, and implement
privileged constraints at a lower level.
Perhaps by the time Java 8's EOL'd there will be a new platform and
language that's more suitable.
Thank you for your time, I do appreciate your replies and it gives me
the clarity I needed.
I wish it wasn't the case, but I have to accept that times are changing.
Best of luck for the future my Java friends, it's been a powerful
language, especially with regard to concurrency and scaling, we got
great performance, all our hotspots were native methods and Java let us
get close to the metal at low levels as well using bit shift operations
on primitives, that are magnitudes faster than standard string
operations. TLS ran so much faster with stateless session tickets too.
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
