Merge pull request #16176 from s1monw/make_security_non_optional
Make security non-optional
This commit is contained in:
commit
d04ec6eb2c
|
@ -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