Dropping the security manager (was Re: Eliminating the security overhead when not running with a security manager)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Dropping the security manager (was Re: Eliminating the security overhead when not running with a security manager)

Jason Tedor
> Long term then it would be interesting to explore degrading and eventually dropping the security manager but that is beyond the scope of what I would like to discuss here.

That is a bold topic to immediately declare out of scope. I am looking for somewhere to reply, so I am forking this thread to a new subject to share my thoughts.

I am an engineer on the Elasticsearch team at Elastic. Elasticsearch is a popular server application implemented in Java that runs on the JVM. We run with the security manager enabled, and there is no option to disable it. We have two major motivations for using the security manger:
- as a server application, to reduce the scope of any exploits in the JDK, our code, or our third-party dependencies (e.g., prevent directory traversals, prevent RCE, etc.)
- we provide a plugin framework (e.g., to add scripting languages) and use the security manager to sandbox untrusted code

For additional background, please see the mail thread "SecurityManager environments" on jigsaw-dev[1].

>The bigger question is of course whether it is interesting to run with a security manager in 2017.

Of course it is. Java is often used to code servers[no citation needed]. The question should be: what can be done to make using the security manager easier for servers[2]? When looking at the major exploits in the Java ecosystem in the last few years (e.g., the commons collections CVE[3] that led to RCE in e.g., JBoss (among others), the Apache Struts CVE[4] that played a role in the Equifax breach), every time my mind turns to: this would not be as large a problem if the server was using the security manager. The JDK needs to be a platform that enables developing secure server applications. Seeing this question raised without any explicit or implicit mention of this need is surprising.

> We have seen a few cases where applications set a security manager in order to enforce some policy, like preventing plugins calling System.exit but these are cases that would be better served with other solutions.

We do this[5][6], although we had to wrap the security manager in our own implementation[7] because we still need to be able to exit on our own[8][9]. However: an API to serve this use-case solely is not enough to meet our current needs from the security manager.

> A big challenge is the System.setSecurityManager API as allows a security manager to be set in a running VM.

We use the System#setSecurityManager API[10][11]. I do not think our use-case is unreasonable: there are privileges that are required upfront, and then we drop them. I am okay with the run mode that you propose (as long as System#setSecurityManager in this run mode is not a no-op but a hard exception), I am not okay with dropping this API entirely (so do not deprecate the System#setSecurityManager API).

[1]: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012044.html
[2]: https://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf
[3]: https://www.cvedetails.com/cve/CVE-2015-6420/
[4]: https://www.cvedetails.com/cve/CVE-2017-5638/
[5]: https://github.com/elastic/securesm/blob/v1.2/src/main/java/org/elasticsearch/SecureSM.java#L75-L83
[6]: https://github.com/elastic/elasticsearch/blob/93a988c557fb4c4a052964d3192a5feb045039ae/core/src/main/java/org/elasticsearch/bootstrap/Security.java#L121-L123
[7]: https://github.com/elastic/securesm
[8]: https://github.com/elastic/elasticsearch/blob/v6.0.0/core/src/main/java/org/elasticsearch/bootstrap/ElasticsearchUncaughtExceptionHandler.java
[9]: https://github.com/elastic/elasticsearch/blob/v6.0.0/core/src/main/java/org/elasticsearch/cli/Command.java#L150
[10]: https://github.com/elastic/elasticsearch/blob/v6.0.0/core/src/main/java/org/elasticsearch/bootstrap/Elasticsearch.java#L75-L82
[11]: https://github.com/elastic/elasticsearch/blob/v6.0.0/core/src/main/java/org/elasticsearch/bootstrap/Security.java#L122-L123

On Mon, Nov 20, 2017 at 9:48 AM Alan Bateman <[hidden email]> wrote:

One of the long standing issues with the security manager support is
that the overhead when there is no security manager is non-zero. Two
specific examples are (i) the overhead of defineClass (assuming the
defining loader is a SecureClassLoader) as it involves a callback to get
the permissions for the protection domain and (ii) the overhead of
AccessController.doPrivileged in order to execute an action on a
privileged stack.

The bigger question is of course whether it is interesting to run with a
security manager in 2017. It's clearly still important for environments
that download potentially malicious code to execute in a sandox but that
isn't most applications these days. We have seen a few cases where
applications set a security manager in order to enforce some policy,
like preventing plugins calling System.exit but these are cases that
would be better served with other solutions.

I would like to explore changes to the API and implementation that would
allow us to eliminate some of the overhead when not running with a
security manager. Long term then it would be interesting to explore
degrading and eventually dropping the security manager but that is
beyond the scope of what I would like to discuss here. Sean Mullan and
Jeff Nisewanger ran an interesting BOF at JavaOne 2017 on this topic and
I believe are planning to do a survey at some point to understand the
current usage of the security manager.

For now I would like to explore what it would take to eliminate some of
the overhead. A big challenge is the System.setSecurityManager API as
allows a security manager to be set in a running VM. This means that
classes loaded before a security manager is set may be involved in
permission checks that happen after a security manager is set.
Similarly, privileged actions may have started before the security
manager is set. The complications around this go away if there was some
way to know that a security manager can never be turned on in a running
system.

To get started, I've put a prototype of an initial proposal on the cr
site [1]. The summary of the proposal is:

1. A "disallow security manager" mode that is opt-in to disallow
setSecurityManager being used to set a security manager in a running VM.
Opt-in means it has not impact on existing code.

2. Deprecates setSecurityManager to discourage further usage and allow
for the possibility of making "disallow security manager" the default in
the future. If that were to become the default then it would have no
impact on deployments that set the security manager on the command line
at startup.

3. When running in "disallow security manager" mode,
AccessController.doPrivileged invokes actions directly and
SecureClassLoader.defineClass skips the callback to get permissions for
the protection domain. This part helps startup and runtime performance.

It's important not to get hung up on the details in the webrev, the
important thing is understand if the security folks on this mailing list
are open to a run mode that prevents a security manager being set in a
running system.

-Alan.

[1] http://cr.openjdk.java.net/~alanb/8191053/webrev/
Reply | Threaded
Open this post in threaded view
|

Re: Dropping the security manager (was Re: Eliminating the security overhead when not running with a security manager)

Alan Bateman
On 23/11/2017 19:21, Jason Tedor wrote:
> > Long term then it would be interesting to explore degrading and
> eventually dropping the security manager but that is beyond the scope
> of what I would like to discuss here.
>
> That is a bold topic to immediately declare out of scope. I am looking
> for somewhere to reply, so I am forking this thread to a new subject
> to share my thoughts.
Starting a new thread is fine as it's beyond the scope of the topic that
I was looking to discuss. As I mentioned, Sean and Jeff are planning a
survey and that would be a good time to bring up use-cases and suggestions.


> The JDK needs to be a platform that enables developing secure server
> applications. Seeing this question raised without any explicit or
> implicit mention of this need is surprising.
Sorry, that's a bit unfair as there has been massive effort put into the
platform to support the development of secure applications. Security is
much more than the security manager.

-Alan