On Wed, Apr 21, 2021 at 8:38 PM Ron Pressler <ron.press...@oracle.com> 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 <ron.press...@oracle.com> 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.
