Re: JEP411: Missing use-case: Monitoring / restricting libraries
On Wed, Apr 21, 2021 at 8:38 PM Ron Pressler wrote: > Its current events might be not have everything you want, but will be > expanded, in > part to address the functionality that will be lost with the removal of > Security Manager. I agree that monitoring needs to be improved since there is a lack of monitoring APIs except for JFR. Until those monitoring APIs are on par with the usage of SM "monitoring", it makes no sense to remove without providing alternatives. > Libraries that can disable the Security Manager aren’t able to circumvent > OS-level > sandboxing. If you’re not afraid of that, then they’re trusted and JFR is > superior; > if they’re untrusted, then configuring the Security Manager correctly for > untrusted rich > libraries is very difficult. Since you said that it cannot circumvent OS-level sandboxing, what will prevent those libraries to monitor if there is JFR active and become dormant until there is no JFR present, then it will execute the malicious behavior; Or, the library attempts to hide or render the JFR useless so that it will not be recorded and noticed? On Wed, Apr 21, 2021 at 8:55 PM Ron Pressler wrote: > For rich libraries and applications, your best bet is an OS-level sandbox. > The Security Manager > might give you a false sense of security. Yes, OS-level sandbox is good but can it be scalable for many types of end users that have different OS and hardware environments? In addition, how many end users out there have used sandbox to isolate their desktop applications except if the program has built-in sandbox such as web browsers? Programs such as Docker does not count.
Re: JEP411: Missing use-case: Monitoring / restricting libraries
Hi Markus, thank you for giving me the guidance for performing the JFR programmatically. I am able to test if my use case is suitable. Where do I provide my feedback/issue of using the streamed JFR? On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund wrote: > If the existing event probes in the JDK does not give you the information you > need, like the name of URL's, it can be a reached by building your own > "custom events" via the Events API [3]. It can be harder to add events to > unknown code dynamically, but it can be done and you can use > java.lang.Instrument to build an agent to inject the custom event. I understand that new events can be added in code that I have control of using the Events API but in this case, which is the name of URLs is not feasible. Firstly, using a Java agent to instrument bytecode cannot be scaled because there are a lot of HTTP libraries, including the built in Java APIs and 3rd parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP wrapper" if the author doesn't want dependency. In addition, these 3rd party libraries can be shaded and relocated, making it harder to target via instrumentation. Obfuscation can also have an impact on reliability of instrumentation, since obfuscation can be changed in every version and what if the obfuscation has "anti-tamper/anti-debug" features? This is not scalable if we need to monitor for each library that might call URLs. > If there is a general problem area and provides a good scaling factor, and > the URL information might just be such a case, it can make sense to > investigate if this information can be provided directly by the JDK, by > extending existing or new JFR events. I believe that the majority of the HTTP libraries, and code that roll their own are using the built in Java APIs, thus monitoring the built in API that is used for making URLs calls make sense. Then, it can be scaled to most of the libraries compared to instrumenting each one which has its own problem stated above.
Re: JEP411: Missing use-case: Monitoring / restricting libraries
> Monitoring network connections can be done with JFR. It will tell you which > classes > perform the connections. It does not require a Java agent. Hi Ron, I read about the JFR and it required a command line argument "-XX:StartFlightRecording" and it is not suitable since it is distributed to the *end user*. Does JFR able capture the URLs performed by those libraries (which can be obtained by getting the name of URLPermission)? I have used it before in JMC and it only shows the hostname address only. Is there an alternative besides JFR that is capable of using programmatically means like SM such as setSecurityManager, ability to capture logs, perform blocking in real time? If JFR is capable of operating *without using command line flags*, can you please link it to the relevant documentation? Besides that, if using JFR streams, can it be used with JMC concurrently? > Setting up the SM to *block* connections while also not allowing those > libraries to > disable the SM is not very easy. Well if those libraries are able to disable SM, those libraries are able to circumvent the native restrictions of the operating system too. But these mostly occur in malicious-like libraries that are less well known or in the worst possible case, popular libraries that are hijacked. >Those libraries are trusted, and monitoring is more effective than sandboxing >for trusted code. I disagree to a degree, not all libraries can be vetted by the operators of the websites, especially those who do not use those distribution websites. This is because some of the libraries might be obfuscated by the library authors themselves and thus unable to determine the trustworthiness, or libraries are unknowingly tampered by 3rd parties. Not every end user will know how to perform hash checking of the downloaded library, even more on verifying the signature of the library. The users implicitly trust because they assume the distribution sites will perform checks on the library for malicious code. They rely on users reporting the library that is malicious. This means that there is a chance that untrustworthy code is executed before knowing it. In addition, assume if the end user needs to decide if the library is "trusted" before they introduce it to the game, but not everyone has the knowledge to audit those libraries themselves. For example, if I have downloaded a modpack that contains 100 mods (which are libraries that are bundled together), do I need to audit each one or will the producer of the pack perform the audit? I believe it will be a waste of time since some of the library is frequently updated with features and bug fixes. For a hypothetical scenario: I have developed a popular library that has intuitive APIs, and this library is constantly updated with features and in one day, I have added a "subtle feature" to gather and upload sensitive information of the monetization purpose and this code is not found in the source. Assuming the user has a monitoring library using the JFR streams, it was able to detect the unknown remote connection to the author server, but it is already too late since when you see the log, it has already happened. I would like to ask in this scenario, what is the best possible solution to mitigate it for the end user perspective besides not downloading it since it can be included implicitly as a dependency, and how can I help the end user to mitigate this scenario? - Lim On Wed, Apr 21, 2021 at 4:24 PM Ron Pressler wrote: > > Monitoring network connections can be done with JFR. It will tell you which > classes > perform the connections. It does not require a Java agent. > > Setting up the SM to *block* connections while also not allowing those > libraries to > disable the SM is not very easy. Those libraries are trusted, and monitoring > is > more effective than sandboxing for trusted code. > > — Ron > > > On 21 Apr 2021, at 06:26, Lim wrote: > > > > Hi all, apologize if I interrupted this thread. > > > > I agreed on what Reinier has said and I have similar concerns about > > the removal of SecurityManager. > > > > I have developed a "Mod" for a certain game to monitor which "Mods" > > are using network connections. The mod is a kind of library since > > other libraries can use them to extend the library functionality such > > as add-on. In this context, library refers to Mod, a modification that > > can provide extra features to the base game. These libraries are > > usually obtained from reputable websites by the end user. However, not > > all libraries can be obtained in these websites, some which are hosted > > by the author themselves that are readily compiled. > > > > Most of the library in this game does not require network connections > > to work except, for legit
Re: JEP411: Missing use-case: Monitoring / restricting libraries
Hi all, apologize if I interrupted this thread. I agreed on what Reinier has said and I have similar concerns about the removal of SecurityManager. I have developed a "Mod" for a certain game to monitor which "Mods" are using network connections. The mod is a kind of library since other libraries can use them to extend the library functionality such as add-on. In this context, library refers to Mod, a modification that can provide extra features to the base game. These libraries are usually obtained from reputable websites by the end user. However, not all libraries can be obtained in these websites, some which are hosted by the author themselves that are readily compiled. Most of the library in this game does not require network connections to work except, for legitimate reasons such as version checker, downloading required resources, but some requested network connections anyway without reasons. This gives the concern, are the network calls justified for a game that can be played offline? Besides that, Reinier gives good point of why the ability to deny/allow network is important and I would like to give an example when I am developing the library: On 2021-04-16 09:29, Reinier Zwitserloot wrote: > * Any library could have the bright idea to 'phone home' and make a > network call simply to give the library author some idea of how > widespread their library is used. This could have an entirely innocuous > purpose: The library author thought it'd be a cool idea to have a live > map of the planet on their website, with a little animated blip every > time their library is used to, say, parse some JSON. SecurityManager is > the simplest way to spot this and stop it. Although most of the recent libraries do not have analytics that I've seen, I have seen one older version of the library that has analytics enabled without any way to disable except performing bytecode modifications. This has implications to the users' privacy since they do not anticipate it has analytics within them and libraries that have analytics are frowned upon in the mod community. This also violates some of the privacy laws in some countries. The security manager is the only viable way to control these libraries from "phone home" in my opinion. Since the end user "install" these libraries by putting into a specific folder for the loader to launch the game with these modifications. They are not expected to change their system just to know if a particular library has these "features". For example, using firewall/hosts file/DNS/other monitoring tools. It might help but it does not provide insight into which class/package which Reinier has said and that's where the SecurityManager can help. By using the "checkConnect" methods in SecurityManager, I can allow/deny and notify appropriate messages in the log for the end user to check. In addition, there is a configuration that allows the end user to configure which hosts are allowed for the network connections. I hope that the core SecurityManager functionality will be preserved. Will there be an alternative that is able to provide similar functionality through programmatic means for my use case? I have read the comments about using JFR stream/bytecode instrumentation but it required the usage of Java Agent and command line flags which is not acceptable in this use case. Thanks
