Evaluate the permission change for jackson-databind

[ryanbogan]

Coming from #5366 (comment) in order for jackson-databind to be used in the server folder, the SHAs, licenses, and notices had to be removed from all plugins and modules. They still have access to jackson through server, but the discovery-ec2 plugin also had the accessDeclaredMembers and suppressAccessChecks permissions in the build.gradle. For the plugin to function properly with the jackson relocation, these permissions were added to the server build.gradle. We need to evaluate whether there are any unintended consequences of adding these permissions.

Link to jackson relocation PR: #5366

[anasalkouz]

@davidlago, any thoughts?

[dblock]

cc: @peternied

[peternied]

suppressAccessChecks
Warning: Extreme caution should be taken before granting this permission to code, for it provides the ability to access fields and invoke methods in a class. This includes not only public, but protected and private fields and methods as well.

This is dangerous in that information (possibly confidential) and methods normally unavailable would be accessible to malicious code.

From https://docs.oracle.com/javase/7/docs/api/java/lang/reflect/ReflectPermission.html

---

These permissions govern allow for the finding, altering, and executing private, protected, ... etc methods. By allowing these permissions it will be possible for the code in server to bypass access protections. Many serialization libraries rely on this reflection so its usage is not surprising.

Having these permissions creates exposure of the code under server/... via tampering. I'd recommend we remove these permissions since server/... does things like establishing TLS, access control systems, or other security features.

The databind library is used for readFromExtensionsYml(...) in ExtensionsManager. Is this the only place its needed - maybe we can look at an alternative approach? Alternatively, would it be possible to sandbox this usage so the permission doesn't need to be broadly available in code under server/... ?

OpenSearch/server/src/main/java/org/opensearch/extensions/ExtensionsManager.java

Lines 537 to 541 in 57d4485

	private ExtensionsSettings readFromExtensionsYml(Path filePath) throws IOException {
	ObjectMapper objectMapper = new ObjectMapper(new YAMLFactory());
	InputStream input = Files.newInputStream(filePath);
	ExtensionsSettings extensionSettings = objectMapper.readValue(input, ExtensionsSettings.class);
	return extensionSettings;

[dblock]

@rmuir @uschindler, since we were just talking about JSM, maybe you have a moment to pitch in your 0.02c here

[uschindler]

You can apply the policy only to a specific jar file, but then you need to make sure that the code there uses AccessController.doPrivilegedvl around the reflection code.

If not you would need to somehow otherwise sandbox it, by delegating all calls to that library sandbox through a proxy that sets the caller domain.

[uschindler]

We had a test in Lucene doing something like this, but this was actually to limit the permissions to run some code without any permission. I have to look it up.

[rmuir]

@rmuir @uschindler, since we were just talking about JSM, maybe you have a moment to pitch in your 0.02c here

As far as the specific permissions, the risk IMO here really involves protection against untrusted code. The vectors for the untrusted code could be things such as scripting features, java serialization, etc. Historically (pre-java 9), if code could just call setAccessible then it is trivial to escape security manager sandbox, just manipulate some private members and you are good to go. But IMO, if code is untrusted and someone wants badly enough to escape the sandbox, they will find a way to do it: one reason we don't run applets in our browsers anymore. So it is best to not be in a situation of executing untrusted code to begin with.

Probably a few things have changed since java 8.x times where we did a lot of cleanup around these permissions:

• vectors seem a lot less scary (e.g. there isn't integrated groovy scripting module any more)
• module system may provide some protection against this kind of stuff (at least for jdk classes) ???