Disabling the builder sandbox removes the default capability restrictions placed on RUN statements, potentially allowing malicious programs to escape the container and access the host system.

Why is this an issue?

By default, programs executed by a RUN statement use only a subset of capabilities which are considered safe: this is called sandbox mode. Using the --security=insecure option disables this sandbox and allows the executed command to use the full set of Linux capabilities.

What is the potential impact?

Container escape

An attacker who controls the behavior of the executed command can use unrestricted capabilities to break out of the container. For example, a program with access to SYS_ADMIN can mount devices from the host system.

Infrastructure compromise

After a successful container escape, the attacker gains access to the host system and can compromise the broader infrastructure, leading to theft of intellectual property or personal data, extortion, or denial of service.

How to fix it

Code examples

The following code example is vulnerable because the --security=insecure option disables the default sandbox, granting the executed program the full set of Linux capabilities.

Noncompliant code example

# syntax=docker/dockerfile:1-labs
FROM ubuntu:22.04
RUN --security=insecure ./example.sh # Noncompliant

Compliant solution

# syntax=docker/dockerfile:1-labs
FROM ubuntu:22.04
RUN --security=sandbox ./example.sh

If elevated capabilities are absolutely necessary for the build to succeed, verify the integrity of the program before executing it with --security=insecure. For example, validate the program’s checksum or cryptographic signature in a preceding RUN statement before allowing the insecure execution.

Resources

Documentation

Standards