
Before this change, Ironic did not filter file:// paths when used as an image source except to ensure they were a file (and not, e.g. a character device). This is problematic from a security perspective because you could end up with config files from well-known paths being written to disk on a node. Now, we forbid any path that provides access to system configuration, including /dev, /sys, /proc, /boot, /run, and /etc. Additionally, we've added an allowlist configuration item which limits the acceptable paths under which images will be pulled to a list provided by the operator. The allowlist default list is huge, but it includes all known usages of file:// URLs across Bifrost, Ironic, Metal3, and OpenShift in both CI and default configuration. Generated-by: Jetbrains Junie Closes-bug: 2107847 Change-Id: I2fa995439ee500f9dd82ec8ccfa1a25ee8e1179c
27 lines
1.4 KiB
YAML
27 lines
1.4 KiB
YAML
---
|
|
security:
|
|
- |
|
|
Fixes OSSA-2025-001, where Ironic did not properly filter file:// paths
|
|
when used as image sources. This would permit any file accessible by the
|
|
conductor to be used as an image to attempt deployment. Ironic now
|
|
unconditionally forbids paths that provide access to system
|
|
configuration (/dev, /sys, /proc, /boot, /run, and /etc).
|
|
|
|
Adds ``CONF.conductor.file_url_allowed_paths``, an allowlist configuration
|
|
defaulting to ``/var/lib/ironic``, ``/shared/html``,
|
|
``/opt/cache/files``, ``/vagrant``, and ``/templates``,
|
|
permits operators to further restrict where the conductor will fetch
|
|
images for when provided a file:// URL. This default value was chosen
|
|
based on known usage by projects downstream of Ironic, including Metal3,
|
|
Bifrost, and OpenShift. These defaults may change to be more restrictive
|
|
at a later date. Operators using file:// URLs are encouraged to explicitly
|
|
set this value even if the current default is sufficient. Operators wishing
|
|
to fully disable the ability to deploy with a file:// URL should set this
|
|
configuration to "" (empty).
|
|
|
|
This issue only poses a significant security risk when Ironic's
|
|
automated cleaning process is disabled and the service is configured in
|
|
such a way that permits direct deployment by an untrusted API user, such as
|
|
standalone Ironic installations or environments granting ownership of nodes
|
|
to projects.
|