[External] : Re: JEP draft: Disallow the Dynamic Loading of Agents by Default

[Mike Hearn]

> we’ve begun to explore means other than the flag to allow a tool to load an agent at runtime

How about restricting access to the jcmd socket. For in-VM code it can
be blocked at the filesystem implementation level, and for
sub-processes by using the operating system APIs to determine if the
other side of the socket is part of the same process tree at connect
time. This would avoid the need for new UI to re-enable existing jcmd
functionality, whilst preventing code loaded into the VM from
connecting back to that same VM. Only truly external tools could
trigger agent loading, or modules that had been given permission to do
that.

That is assuming native code is restricted of course but that's a
whole other kettle of fish. I don't quite understand how the plan is
meant to work when it reaches that stage. JNI is so widely used and so
many libraries would break that you'd either just immediately see
workarounds appear, like build systems concatenating lists of flags
from META-INF files, or it'd just cause a lot of chaos and upgrade
rejection. It'd also have to be dynamically controllable for plugins,
so then you'd also get people running their apps inside classloaders
that auto-grant any request to load native code.

There must be a better way?

Maybe the problem can be recast as one of build-time observability?
One concept I experimented with for my own build system is the notion
of "control reports", a generalization of lockfiles. The build
generates text files describing things you care about, and these are
then checked in to vcs. There is a build mode that doesn't write the
generated reports on disk, instead it verifies there's no difference
and exits if there are. By checking the reports into version control
and using OWNERS files + code reviews various policies can be
enforced.

In this context it'd work like so: the JVM would be changed to look
for a flags file in the JAR containing the main class/main module as
part of its startup. JVM flags can thus be shipped as part of the app,
formalizing an already existing convention that's today implemented
with shell scripts. Build systems can generate this flag file from
their existing lists of JVM flags, and/or compute it automatically by
merging flag files found in any library JARs. For people who don't
care about deprivileging libs (prototyping, learners, people who only
use in-house code etc) this will keep things working as it does today.
For people who wish to use this new security feature they can review
the generated flag file and check it in. Now if they add a dependency
on a library that needs to use panama, jni, an agent, opened packages
etc, this will become visible as added lines in the flag file, can be
pushed back on when the commit is reviewed, and by placing an OWNERS
file in the directory containing the report tech leads can allow
delegates to add dependencies without being able to change JVM flags.