[Entitlements] Exclude java.desktop from system modules

[ldematte]

When we realized we have missed instrumentation of URL.openConnection methods, we tried to see if we could also chase usages of these functions across the codebase, as an alternative to instrument URLConnection classes (the return type). There were many uses, and complex ones, so we ended up doing the URLConnection instrumentation, but we also realized that Elasticsearch still loads the java.desktop module. Collective memory seems to remember we have it for just a couple of encoding/decoding functions; however, since we now "skip" verification for system modules, all calls to file and network operations form java.desktop are permitted, which exposes a huge surface (there might be something exploitable there).

This PR removes the java.desktop module explicitly (with the ability to add more if we need to) from the set of "system modules". We should not need any entitlement for java.desktop (we should barely use it, and not use it for any sensitive operation); however if it turns out that we need let java.desktop perform some sensitive operation, we can explicitly add that back to the server policy, e.g. adding:

new Scope("java.desktop", List.of(new LoadNativeLibrariesEntitlement())),

to serverScopes in EntitlementInitialization.

Testing this with a IT test is difficult/impossible, as we are talking about server policies.
I've tested this manually in the following way:

• add this code to server (e.g. where we perform self-checks after Entitlement bootstrap):

try {
   var x = ImageIO.read(nodeEnv.configDir().resolve("image.png").toFile());
   logger.info("ImageIO Entitled");
} catch (NotEntitledException e) {
   logger.info("ImageIO Not entitled");
}

(ImageIO is just a "convenient" class I found in java.desktop

• run it as it is today --> "ImageIO Entitled"
• add java.desktop to MODULES_EXCLUDED_FROM_SYSTEM_MODULES --> "ImageIO Not entitled"
• add new Scope("java.desktop", List.of(new LoadNativeLibrariesEntitlement())) to serverScopes in EntitlementInitialization --> "ImageIO Entitled"

I have also:

• observed with the trace logs that access to config is granted by the basic FileAccessTree policy we have
• tried to add the entitlement to a modularized plugin: it does not work (it complains that the module is not in the list of this plugin modules, which is correct)
• tried to add the entitlement to a non-modularized plugin: this of course passes checks
  • but does not grant access (because the module is still considered a (server) module): see next point
• adding the code above to the plugin makes it fail (this is the only thing we can write a IT test for -- added!)
• tried to add the entitlement to server: adding the code above to a plugin works correctly (server policy + call to sensitive method from a plugin)

Relates to: ES-11008

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[prdoyle]

Shouldn't we filter this out of systemModuleDescriptors instead? Otherwise, that set isn't quite right.

[ldematte]

I don't understand your point; systemModuleDescriptors is a local variable. We can filter it out from systemModuleDescriptors, or from here. Am I missing something? Does it make a difference?

[prdoyle]

No, there's no functional difference, but it seems odd to create an incorrect value and then account for that incorrectness later.

It's not a huge deal, since the returned value is unaffected, as you say.

[prdoyle]

Actually, one could argue that the first line is simply collecting whatever ModuleFinder.ofSystem() returns, and it's the second line that's responsible for building the list of system modules that Entitlements needs.

So I'm ok either way.

[ldematte]

Actually, one could argue that the first line is simply collecting whatever ModuleFinder.ofSystem() returns

That's exactly what I was thinking :)

[elasticsearchmachine]

💚 Backport successful

Status	Branch	Result
✅	8.18
✅	8.x
✅	9.0