Using JFR as an alternative of SecurityManager for monitoring network

[Lim]

Hi,

Since the SecurityManager will be deprecated in JEP 411, I have been
evaluating JFR for my use case which is monitoring libraries in a
program for network communications.

So I decided to make sample scenario that describes my use case below:

Main.java [1];
The code have three parts that perform network connections:
  Obtain the IP addresses from hostname.
  Using the older HttpURLConnection method, searched from the internet.
  The new HttpClient method.

NetMonitorSM.java [2];
Using SecurityManager to monitor Network and file usage (".jfr" file
read/write/delete).

NetMonitorJFR.java [3];
Using JFR to monitor Socket Connection, which is the only way to
determine if there are network connections.


Below are the logs that I seen using different methods for the monitoring.

In SM only [4], I can see exactly what is performed before the action is happen.
Note that all sockets connections are logged and with the addition of URL.
The SecurityManager has prefixed with "[SM]". Optionally, I can get the
stacktrace using SecurityManager.getClassContext() if needed.

In JFR Only [5], the first InetAddress connection is not captured by the JFR
with SocketRead and SocketWrite event enabled when SM is able to monitor it.

On HttpURLConnection - The message is display after getting the reply from
the website which is on "[16:00:13.444]". In line 7, the message displayed
on [16:00:13.499] but the action has happened on StartTime='16:00:13.058'
with "Write Event". Note that there is the continuation of the events
until all the bytes has been read/written.

On HttpClient - which starts from line 120 "[16:00:15.488]" shows the
similarity as the above but the first two events are useless because
the "Host", "Address" and "Port" does not record the actual destination.
Only after the third event, I can obtain the useful information but
at the same time, the StackTrace information become useless since it
does not show the originating class.

With both SecurityManager and Java Flight Recorder enabled [6],
It gives an interesting insight of how SM interacts with JFR.
First is the SM logs are shown first before the JFR event shows.

Unexpectedly, The SM managed to monitor the *reading and writing file* by the
JFR that I *explicitly used streamed version*. Why does JFR in this case
create temp files and delete it? Without security manager, I wouldn't have
know Streamed JFR write to disk. Shouldn't the stream is only kept in memory?


I have several questions about JFR, particularity the streamed version

1. I not sure why "jdk.jfr.internal.tool.PrettyWriter" is not exposed
because I found useful method like "formatMethod" so that I do not need
to manually parse the stacktrace in my JFR code [3].

2. Is it an implementation detail that using Streamed JFR create/delete
files on disk? Since if the program crash/force terminate, the temp .jfr
is not deleted and depending on the events enabled, it can consume a lot
of disk space.

3. Currently the streamed event are show *after* the network calls are
happened, while the SM is show *before* the network calls took place.
Although there is "StartTime" which shows the exact time when the
event happened, it is not show orderly in the log [5][6].

4. Is there way to get "before" an actual event is occurred like:
rs.beforeEvent("jdk.SocketWrite", System.out::println) so that the log
is shown like in the SecurityManager implementation [4].

5. In the HttpClient method of calling network, the first 2 events
address and host is not actual destination, and the port seems random.
Is this normal because the host is not resolved yet?

6. Will JDK-8265962 - "Evaluate adding Networking JFR events", that was
described on another thread [7], will address the InetAddress if implemented?

I think that using JFR is a good approach but it is far from usable in
my use case, I'm not sure this is the best practice for using JFR in
programmatic way and how can it be improved. Or if possible, how do I
make it "emulate" the behavior of SM?

Thanks

[1] https://paste.ee/p/vCfZr#section0
[2] https://paste.ee/p/vCfZr#section1
[3] https://paste.ee/p/vCfZr#section2
[4] https://paste.ee/p/Mzczr#section0
[5] https://paste.ee/p/Mzczr#section1
[6] https://paste.ee/p/Mzczr#section2
[7] https://mail.openjdk.java.net/pipermail/security-dev/2021-April/025633.html