* java.base entitlements
* SuppressForbidden, and add a missing test
* Revert logging back to commented-out printlns
* Merge FileCheckActions and rename for overloads
* Remove stray logger
* Remove more traces of logging change
* Remove more traces of logging
With Security Manager we have SecuredConfigFileSettingAccessPermission.
This commit adds an entitlement equivalent. With each entry in files
entitlement, a `path_setting` can now be used. The value may be an
explicit setting, or a setting glob with a single `*`.
relates ES-10844
This commit switches to using records in place of classes for FileData
impls. It moves them outside the interface so that they can be private.
This does not change the fact the interface is sealed, nor the factory
methods for creating them.
While testing https://github.com/elastic/elasticsearch/pull/122591, I
realized we need to grand read/write permission to the logs dir to
server.
This PR adds the `logsDir` to the bootstrap parameters, and uses it in
the `server` policy.
Currently the SLM health indicator in health report turns YELLOW when snapshots fail for a number of times. However, the SLM health indicator stays GREEN if snapshot is not completed (no success or failure) for a long time. This change adds a new optional setting unhealthy_if_no_snapshot_within to SLM policy, that sets a time threshold. If the SLM policy has not had a successful snapshot for longer than the threshold, the SLM health indicator will turn YELLOW.
Temp dir access is necessary all over Elasticsearch, and in general is
not sensitive. With Security Manager all code in ES, including plugins,
are given read/write access to the temp dir. This commit mimicks that
behavior with entitlements.
This commit adds instrumentation for File methods that require write
permission. No server or plugins use these methods, so no policy changes
were necessary. Note that since we are not planning to restrict temp
file creation, the bootstrap self test on file writing was removed,
which failed with these changes.
This commit removes "TLSv1.1" from the list of default protocols in
Elasticsearch (starting with ES9.0)
TLSv1.1 has been deprecated by the IETF since March 2021
This affects a variety of TLS contexts, include
- The HTTP Server (Rest API)
- Transport protocol (including CCS and CCR)
- Outgoing connections for features that have configurable SSL
settings. This includes
- reindex
- watcher
- security realms (SAML, OIDC, LDAP, etc)
- monitoring exporters
- inference services
In practice, however, TLSv1.1 has been disabled in most Elasticsearch
deployments since around 7.12 because most JDK releases have disabled
TLSv1.1 (by default) starting in April 2021
That is, if you run a default installation of Elasticsearch (for any
currently supported version of ES) that uses the bundled JVM then
TLSv1.1 is already disabled.
And, since ES9+ requires JDK21+, all supported JDKs ship with TLSv1.1
disabled by default.
In addition, incoming HTTP connections to Elastic Cloud deployments
have required TLSv1.2 or higher since April 2020
This change simply makes it clear that Elasticsearch does not
attempt to enable TLSv1.1 and administrators who wish to use that
protocol will need to explicitly enable it in both the JVM and in
Elasticsearch.
Resolves: #108057
Like the plugin being testing, the entitled test plugin needs access to
dynamic elements (namely, file paths). This commit dynamically generates
the entitlement policy for the entitlted test plugin when it is
installed. It also adds using the file entitltlement as an example.
The only real path separators are either forward or back slash. Trying
to use something else like newline fails to even parse as a path on
windows. This commit removes testing of other separators.
closes#121872
