> In reply to Ron Pressier: > Do you regularly use the Security Manager to sandbox your own dependencies > and find it convenient and effective > — in which case, could you please describe your practice concretely so that > it would be possible to consider > alternatives — or are you saying that you can *envision* such a powerful > use-case? The desire to remove the > Security Manager does not stem from its theoretical utility, which is > absolutely amazing, but from its practical > utility, which years of experience have found to be less than amazing after > all, and probably too low to justify > its burdensome cost.
# Practical example of SecurityManager use We are developing a security and privacy conscious browser in pure Java: https://gngr.info `gngr` uses `SecurityManager` at its core to not only sandbox external libraries but also *internal modules*! # External Libraries we use * `Rhino` for Javascript * `jStyleParser` for CSS parsing and analysing * `okhttp` for HTTP/2 support (before the Java11 HTTP client was available) These are huge libraries that are practically impossible to audit by a small team, but through the SecurityManager we were able to identify the following issues very easily: ## Security issues discovered so far * Network access by the CSS parser library: https://github.com/radkovo/jStyleParser/issues/14 * Use of reflection to make a private method accessible https://github.com/square/okhttp/issues/3426 # Trust, but verify We don't use `SecurityManager` because we don't trust the external library authors; we do trust them else we wouldn't be using those libraries! And given that these are popular projects, we can also bank on oversight from the community at large. But what if we could also verify this trust and other assumptions, for very little overhead? The SecurityManager does require initial time investment, but IMO the returns justify it. A good example of trust but verify, is our own internal modules. We obviously trust our own code, yet we sandbox it, to be sure that our assumptions are correct. For example, the `Cookie` module inside the browser only needs File access, in order to persist the cookies. Having it sandboxed relieves us from worrying about some bug or debug code mistakenly accessing the internet or any of the other myriad capabilities that the code has access to. # Numbers are misleading One argument I have seen in support of JEP 411 is that there are very few projects that use the SecurityManager. But this outcome seems natural to me: 1. Many users and developers are not aware of Security threats, or don't give enough priority to them. 2. The SecurityManager is hard to setup. I expect #1 to change over a period of time, as more data gets breached and more people learn from this experience. #2 could be solved with better documentation, tutorials, etc. Or through development of an alternative API. (Imagine if WeakReferences were removed from the JVM because they were not used by many projects! Of course, they won't be used by many projects because they are not relevant to most of them. However, for the projects that do use them, they are very essential.) # Logging events violates POLP The alternative of using logging, with JFR for example, might be suitable for certain use-cases, but is not a general replacement for the protections provided by SecurityManager. For one, it might not be possible to exercise all code-paths in tests. Hence, the events made during testing might be a subset of the actual behavior in production. Secondly, it is not possible to know all events that need to be captured in advance. Using a SecurityManager allows us to follow a whitelisting policy, which is practical because the white list is finite. However, the alternative of logging events requires us to list all possible capabilities in advance, which is impossible, as the capabilities provided by the JVM or the standard library might grow in a future version. Thirdly, using Java agents with bytecode manipulation, as suggested on this list, doesn't seem any easier than using the SecurityManager. best, -- Harshad RJ