Merge pull request #164 from stackhpc/upstream/wallaby-2022-09-12

Synchronise wallaby with upstream

doc/source/admin/kolla_api.rst

@@ -93,27 +93,17 @@ Here is an example configuration file:
 Passing the configuration file to the container
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The configuration can be either passed via the ``KOLLA_CONFIG`` environment
-variable or as a file bind-mounted into the container. When bind-mounting the
-configuration file, the ``KOLLA_CONFIG_FILE`` environment variable controls
-where the file is located in the container, the default path being
+The configuration to the container can be passed through a dedicated path:
 ``/var/lib/kolla/config_files/config.json``.
-
-Passing the configuration file as environment variable:
-
-.. code-block:: console
-
-   docker run -e KOLLA_CONFIG_STRATEGY=COPY_ALWAYS \
-       -e KOLLA_CONFIG='{ "command": "...", "permissions": [ { "path": "...", } ] }' \
-       kolla-image
+It is advised to ensure this path is mounted read-only for security reasons.
 
 Mounting the configuration file in the container:
 
 .. code-block:: console
 
    docker run -e KOLLA_CONFIG_STRATEGY=COPY_ALWAYS \
-       -e KOLLA_CONFIG_FILE=/config.json \
-       -v /path/to/config.json:/config.json kolla-image
+       -v /path/to/config.json:/var/lib/kolla/config_files/config.json:ro \
+       kolla-image
 
 .. _kolla_api_environment_variables:
 
@@ -126,10 +116,6 @@ Variables to pass to the containers
 The Kolla containers also understand some environment variables to change their
 behavior at runtime:
 
-* **KOLLA_CONFIG**: load kolla config from the environment, takes precedence
-  over ``KOLLA_CONFIG_FILE``.
-* **KOLLA_CONFIG_FILE**: path to kolla json config file, defaults to
-  ``/var/lib/kolla/config_files/config.json``.
 * **KOLLA_CONFIG_STRATEGY** (required): Defines how the :ref:`kolla_start
   script <kolla_api_external_config>` copies the configuration file. Must be
   one of:

docker/base/set_configs.py

@@ -272,21 +272,8 @@ def validate_source(data):
 
 
 def load_config():
-    def load_from_env():
-        config_raw = os.environ.get("KOLLA_CONFIG")
-        if config_raw is None:
-            return None
-
-        # Attempt to read config
-        try:
-            return json.loads(config_raw)
-        except ValueError:
-            raise InvalidConfig('Invalid json for Kolla config')
-
     def load_from_file():
-        config_file = os.environ.get("KOLLA_CONFIG_FILE")
-        if not config_file:
-            config_file = '/var/lib/kolla/config_files/config.json'
+        config_file = '/var/lib/kolla/config_files/config.json'
         LOG.info("Loading config file at %s", config_file)
 
         # Attempt to read config file
@@ -300,9 +287,7 @@ def load_from_file():
                 raise InvalidConfig(
                     "Could not read file %s: %r" % (config_file, e))
 
-    config = load_from_env()
-    if config is None:
-        config = load_from_file()
+    config = load_from_file()
 
     LOG.info('Validating config file')
     validate_config(config)

docker/base/sudoers

@@ -6,6 +6,8 @@
 # anyone in the kolla group may sudo -E (set the environment)
 Defaults: %kolla setenv
 
+Defaults secure_path="/var/lib/kolla/venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+
 # root may run any commands via sudo as the network seervice user.  This is
 # neededfor database migrations of existing services which have not been
 # converted to run as a non-root user, but instead do that via sudo -E glance

releasenotes/notes/bug-1985784-59df54a10a004551.yaml

@@ -0,0 +1,16 @@
+---
+security:
+  - |
+    Fixes CVE-2022-38060, a sudo privilege escalation vulnerability.
+    `LP#1985784 <https://launchpad.net/bugs/1889611>`__
+upgrade:
+  - |
+    To fix CVE-2022-38060, support for KOLLA_CONFIG and KOLLA_CONFIG_FILE
+    environment variables in kolla-built containers has been dropped.
+    Now, only the single trusted path of
+    ``/var/lib/kolla/config_files/config.json`` will be utilised for loading
+    container config.
+    We believe this is a reasonable tradeoff as these environment variables
+    were not used by any known downstream and potential users in the wild
+    can easily adapt as this does not limit the functionality per se, only
+    making it stricter as to where the config can come from.

tests/test_set_config.py

@@ -59,24 +59,6 @@ def test_load_ok(self):
                 mock.call().__exit__(None, None, None)], mo.mock_calls)
 
 
-class LoadFromEnv(base.BaseTestCase):
-
-    def test_load_ok(self):
-        in_config = json.dumps({'command': '/bin/true',
-                                'config_files': {}})
-
-        mo = mock.mock_open()
-        with mock.patch.object(set_configs, 'open', mo):
-            with mock.patch.dict('os.environ', {'KOLLA_CONFIG': in_config}):
-                config = set_configs.load_config()
-                set_configs.copy_config(config)
-                self.assertEqual([mock.call('/run_command', 'w+'),
-                                  mock.call().__enter__(),
-                                  mock.call().write('/bin/true'),
-                                  mock.call().__exit__(None, None, None)],
-                                 mo.mock_calls)
-
-
 FAKE_CONFIG_FILES = [
     set_configs.ConfigFile(
         '/var/lib/kolla/config_files/bar.conf',