Migrate Permissions Policy configuration #184939
Labels
enhancement
New value added to drive a business result
Feature:Hardening
Harding of Kibana from a security perspective
Team:Security
Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Comments
legrego
added
Team:Security
|
Pinging @elastic/kibana-security (Team:Security) |
elena-shostak
added a commit
that referenced
this issue
Jul 4, 2024
## Summary 1. Added top-level `permissionsPolicy` configuration setting. 2. Added support for `report_to` directive. 3. Added support for `Permissions-Policy-Report-Only` header to enable reporting mode. 4. The [spec](https://www.w3.org/TR/permissions-policy/#reporting) mentions `featureId` in the reporting body, however the field is `policyId` in Chromium. ## How to test - Add in your `kibana.dev.yml`. ``` server.customResponseHeaders.Reporting-Endpoints: violations-endpoint="https://localhost:5601/kibana/internal/security/analytics/_record_violations" server.securityResponseHeaders.permissionsPolicy: 'microphone=()' server.securityResponseHeaders.permissionsPolicyReportOnly: 'camera=()' ``` - Make sure you have [dev tools configured for Reporting API](https://developer.chrome.com/docs/capabilities/web-apis/reporting-api#use_devtools). - In the browser console invoke `navigator.mediaDevices.getUserMedia({ audio: true, video: true }).catch((e) => {});` - Open Dev Tools -> Application -> Reporting API. You should see 2 reports for permissions violation, one with `report` disposition and another with `enforce` disposition. <img width="1285" alt="Screenshot 2024-06-27 at 13 36 12" src="https://github.com/elastic/kibana/assets/165678770/3f3da7f6-f6b0-4f33-9a81-dff3db0ac2b8"> ### Checklist - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) ### For maintainers - [ ] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Related Issue(s) #175113, #184939 ### Release Note Added support for Permissions Policy reporting.
legrego
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Our permissions policy config is currently defined as a single
server.securityResponseHeaders.permissionsPolicystring, which allows administrators to wholesale override the policy:We should align this configuration to what we do for our Content Security Policy (#102059). The configuration specified in
kibana.ymlshould be treated as additive, rather than replacing our built-in permissions policy.Expand top-level
permissionsPolicyconfiguration settingThis setting should be marked as preview/experimental.
This configuration schema should support the following:
permissionsPolicy.report_to: an optional array of strings, analogous to our currentcsp.report_tosetting.permissionsPolicy.camera: an optional array of strings, which should be included within ourcamera(...)directive.permissionsPolicy.display_capture: an optional array of strings, which should be included within ourdisplay-capturedirective.permissionsPolicy.fullscreen: an optional array of strings, which should be included within ourfullscreendirective.permissionsPolicy.geolocation: an optional array of strings, which should be included within ourgeolocationdirective.permissionsPolicy.microphone: an optional array of strings, which should be included within ourmicrophonedirective.permissionsPolicy.web_share: an optional array of strings, which should be included within ourweb-sharedirective.Deprecate
server.securityResponseHeaders.permissionsPolicyWith the introduction of per-directive configuration, we should deprecate the previous wholesale override, and suggest that users migrate to the new
permissionsPolicy.*set of configuration options.Validation
Users should not be allowed to specify both
server.securityResponseHeaders.permissionsPolicyandpermissionsPolicy.*settings at the same time. Kibana should fail to start if we detect both are in use.Docker
The new settings should be added to
src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-dockerto facilitate configuration within our docker environments.Logic
server.securityResponseHeaders.permissionsPolicynorpermissionsPolicy.*are configured, then Kibana should use its default permissions policy.server.securityResponseHeaders.permissionsPolicyis configured, then Kibana should use the policy specified in yml, and not use its default permissions policy (This should be the current behavior).permissionsPolicy.*is specified, then the directives in the yml file should be added to Kibana's default permissions policy.The text was updated successfully, but these errors were encountered: