JEP411: Missing use-case: Monitoring / restricting libraries

[Harshad RJ]

> 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