Block specific config files from being read after startup #107481
Conversation
thecoop
added
>non-issue
:Security/Security
elasticsearchmachine
added
Team:Core/Infra
|
Pinging @elastic/es-security (Team:Security) |
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
thecoop
added
v7.17.21
auto-backport
elasticsearchmachine
added
Team:Core/Infra
|
Hi @thecoop, I've created a changelog YAML for you. |
server/src/main/java/org/elasticsearch/watcher/FileWatcher.java
Outdated
Show resolved
Hide resolved
qa/evil-tests/src/test/java/org/elasticsearch/bootstrap/ESPolicyUnitTests.java
Show resolved
Hide resolved
qa/evil-tests/src/test/java/org/elasticsearch/bootstrap/ESPolicyUnitTests.java
Outdated
Show resolved
Hide resolved
| private static List<FilePermission> createForbiddenFilePermissions(Environment environment) throws IOException { | ||
| Permissions policy = new Permissions(); | ||
| addSingleFilePath(policy, environment.configFile().resolve("elasticsearch.yml"), "read,readlink"); | ||
| addSingleFilePath(policy, environment.configFile().resolve("jvm.options"), "read,readlink"); |
There was a problem hiding this comment.
What about jvm.options.d ? I know we didn't mention it when we planned this work, but in my mind it was implied by jvm.options.
There was a problem hiding this comment.
I've added a check for that too
|
@elasticmachine update branch |
| @@ -93,17 +106,16 @@ public boolean implies(ProtectionDomain domain, Permission permission) { | |||
| } | |||
| } | |||
|
|
|||
| if (permission instanceof FilePermission) { | |||
There was a problem hiding this comment.
IIRC this was here to avoid the (potentially relatively expensive) implies call on a permission collection. Can we add this conditional back, and also guard the new check in the same way?
There was a problem hiding this comment.
The first thing FilePermissionCollection does is check the type of the argument - which is only duplicated by having a check here. So I don't think it affects much?
| my_stemmer_override: | ||
| type: stemmer_override | ||
| rules_path: "jvm.options" | ||
| - match: { status: 500 } |
There was a problem hiding this comment.
Could we catch this in the same way FileWatcher was modified, to result in a 400 instead of a 500?
There was a problem hiding this comment.
I've changed it to a 400 response code
💔 Backport failed
You can use sqren/backport to manually backport by running |
Block specific config files from being accessed after startup (elastic#107481) Some files should never be accessed by ES or plugin code once startup has completed. Use the security manager to block these files from being accessed by anything at all. The current blocked files are elasticsearch.yml, jvm.options, and the jvm.options.d directory.
Block specific config files from being accessed after startup (#107481) Some files should never be accessed by ES or plugin code once startup has completed. Use the security manager to block these files from being accessed by anything at all. The current blocked files are elasticsearch.yml, jvm.options, and the jvm.options.d directory.
Block specific config files from being read by anything in elasticsearch after startup. There's no reason for anything to read these files after node initialization.