For mounts types secret and ssh, Dockerfile’s RUN instruction supports a mode option for setting permissions. If you set this mode so that any user of the operating system can access the mount, it is vulnerable to leaks.

Why is this an issue?

Docker offers a feature to mount files and directories for specific RUN instructions when building Docker images. This feature can be used to provide secrets to commands that are executed during the build without baking them into the image. Additionally, it can be used to access SSH agents during the build.

The mode option is an octal value that allows you to specify the permissions for a particular file or directory. By default, on Docker, when mounting a secret, it is set to 0400.

For ssh, it is set by default to 0600:

• The first digit 0 stands for special permissions (like setuid, setgid and sticky bit) and in this case means that no special permissions are set.
• The following 6 (4+2 in octal format) means that the owner has read (4) and write (2) permissions
• 00 means that the group and others have no permissions.

If the others bit is set to a value other than 0 at build-time, any other process can access it when the RUN command is executed: the secrets are vulnerable to supply chain attacks that aim to siphon secrets from containers.

What is the potential impact?

Unauthorized access

The unintended audience can exploit the leaked private key or equivalent to authenticate themselves as the legitimate owner, gaining unauthorized entry to systems, servers, or accounts that accept the key for authentication.

This unauthorized access opens the door for various malicious activities, including data breaches, unauthorized modifications, and misuse of sensitive information.

How to fix it

Code examples

Noncompliant code example

# Noncompliant
RUN --mount=type=secret,id=build_secret,mode=0777 ./installer.sh

Compliant solution

RUN --mount=type=secret,id=build_secret,mode=0700 ./installer.sh

How does this work?

In general, always follow the least privilege principle, and set the others bit to 0. By default, if mode is not set, permissions are safe.

In case you made this change because you need to access secrets or agents as a low-privileged user, you can use the options uid and gid to provide access without having to resort to world-readable or writable permissions that might expose them to unintended parties.

Resources

Documentation

• Dockerfile Reference - RUN --mount=type=secret
• Red Hat - Linux file permissions explained

Standards

• CWE - CWE-732 - Incorrect Permission Assignment for Critical Resource
• STIG Viewer - Application Security and Development: V-222430 - The application must execute without excessive account permissions.