Make security non-optional
2.x has show so far that running with security manager is the way to go. This commit make this non-optional. Users that need to pass their own rules can still do this via the system configuration for the security manager. They can even opt out of all security that way.
This commit is contained in:
parent
b77175ec2d
commit
c50586599e
|
@ -175,7 +175,7 @@ final class Bootstrap {
|
|||
JarHell.checkJarHell();
|
||||
|
||||
// install SM after natives, shutdown hooks, etc.
|
||||
setupSecurity(settings, environment);
|
||||
Security.configure(environment, BootstrapSettings.SECURITY_FILTER_BAD_DEFAULTS_SETTING.get(settings));
|
||||
|
||||
// We do not need to reload system properties here as we have already applied them in building the settings and
|
||||
// reloading could cause multiple prompts to the user for values if a system property was specified with a prompt
|
||||
|
@ -188,14 +188,6 @@ final class Bootstrap {
|
|||
node = new Node(nodeSettings);
|
||||
}
|
||||
|
||||
|
||||
|
||||
private void setupSecurity(Settings settings, Environment environment) throws Exception {
|
||||
if (BootstrapSettings.SECURITY_MANAGER_ENABLED_SETTING.get(settings)) {
|
||||
Security.configure(environment, BootstrapSettings.SECURITY_FILTER_BAD_DEFAULTS_SETTING.get(settings));
|
||||
}
|
||||
}
|
||||
|
||||
@SuppressForbidden(reason = "Exception#printStackTrace()")
|
||||
private static void setupLogging(Settings settings, Environment environment) {
|
||||
try {
|
||||
|
|
|
@ -27,14 +27,6 @@ public final class BootstrapSettings {
|
|||
private BootstrapSettings() {
|
||||
}
|
||||
|
||||
// TODO: remove this: http://www.openbsd.org/papers/hackfest2015-pledge/mgp00005.jpg
|
||||
/**
|
||||
* option to turn off our security manager completely, for example
|
||||
* if you want to have your own configuration or just disable
|
||||
*/
|
||||
public static final Setting<Boolean> SECURITY_MANAGER_ENABLED_SETTING =
|
||||
Setting.boolSetting("security.manager.enabled", true, false, Scope.CLUSTER);
|
||||
|
||||
// TODO: remove this hack when insecure defaults are removed from java
|
||||
public static final Setting<Boolean> SECURITY_FILTER_BAD_DEFAULTS_SETTING =
|
||||
Setting.boolSetting("security.manager.filter_bad_defaults", true, false, Scope.CLUSTER);
|
||||
|
|
|
@ -395,7 +395,6 @@ public final class ClusterSettings extends AbstractScopedSettings {
|
|||
PageCacheRecycler.WEIGHT_OBJECTS_SETTING,
|
||||
PageCacheRecycler.TYPE_SETTING,
|
||||
PluginsService.MANDATORY_SETTING,
|
||||
BootstrapSettings.SECURITY_MANAGER_ENABLED_SETTING,
|
||||
BootstrapSettings.SECURITY_FILTER_BAD_DEFAULTS_SETTING,
|
||||
BootstrapSettings.MLOCKALL_SETTING,
|
||||
BootstrapSettings.SECCOMP_SETTING,
|
||||
|
|
|
@ -25,7 +25,6 @@ import org.elasticsearch.test.ESTestCase;
|
|||
public class BootstrapSettingsTests extends ESTestCase {
|
||||
|
||||
public void testDefaultSettings() {
|
||||
assertTrue(BootstrapSettings.SECURITY_MANAGER_ENABLED_SETTING.get(Settings.EMPTY));
|
||||
assertTrue(BootstrapSettings.SECURITY_FILTER_BAD_DEFAULTS_SETTING.get(Settings.EMPTY));
|
||||
assertFalse(BootstrapSettings.MLOCKALL_SETTING.get(Settings.EMPTY));
|
||||
assertTrue(BootstrapSettings.SECCOMP_SETTING.get(Settings.EMPTY));
|
||||
|
|
|
@ -20,6 +20,7 @@ your application to Elasticsearch 3.0.
|
|||
* <<breaking_30_packaging>>
|
||||
* <<breaking_30_scripting>>
|
||||
* <<breaking_30_term_vectors>>
|
||||
* <<breaking_30_security>>
|
||||
|
||||
[[breaking_30_search_changes]]
|
||||
=== Warmers
|
||||
|
@ -767,3 +768,10 @@ The term vectors APIs no longer persist unmapped fields in the mappings.
|
|||
|
||||
The `dfs` parameter has been removed completely, term vectors don't support
|
||||
distributed document frequencies anymore.
|
||||
|
||||
[[breaking_30_security]]
|
||||
=== Security
|
||||
|
||||
The option to disable the security manager `--security.manager.enabled` has been removed. In order to grant special
|
||||
permissions to elasticsearch users must tweak the local Java Security Policy.
|
||||
|
||||
|
|
|
@ -82,7 +82,7 @@ Returns the following exception:
|
|||
[float]
|
||||
== Dealing with Java Security Manager issues
|
||||
|
||||
If you encounter issues with the Java Security Manager, you have three options
|
||||
If you encounter issues with the Java Security Manager, you have two options
|
||||
for resolving these issues:
|
||||
|
||||
[float]
|
||||
|
@ -92,25 +92,6 @@ The safest and most secure long term solution is to change the code causing
|
|||
the security issue. We recognise that this may take time to do correctly and
|
||||
so we provide the following two alternatives.
|
||||
|
||||
[float]
|
||||
=== Disable the Java Security Manager
|
||||
|
||||
deprecated[2.2.0,The ability to disable the Java Security Manager will be removed in a future version]
|
||||
|
||||
You can disable the Java Security Manager entirely with the
|
||||
`security.manager.enabled` command line flag:
|
||||
|
||||
[source,sh]
|
||||
-----------------------------
|
||||
./bin/elasticsearch --security.manager.enabled false
|
||||
-----------------------------
|
||||
|
||||
WARNING: This disables the Security Manager entirely and makes Elasticsearch
|
||||
much more vulnerable to attacks! It is an option that should only be used in
|
||||
the most urgent of situations and for the shortest amount of time possible.
|
||||
Optional security is not secure at all because it **will** be disabled and
|
||||
leave the system vulnerable. This option will be removed in a future version.
|
||||
|
||||
[float]
|
||||
=== Customising the classloader whitelist
|
||||
|
||||
|
|
Loading…
Reference in New Issue