You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It was discovered that exec driver tasks run with full Linux capabilities such that processes can escalate to run as privileged root user, despite running as the Linux unprivileged user, nobody. This vulnerability affects versions 0.9.0 and 0.9.1 of Nomad, both OSS and Enterprise and was fixed in #5728.
Background
Nomad allows running various types of workloads. The exec driver runs processes in a chroot environment and a lightweight container. By default, Nomad 0.8 runs exec processes as nobody user with no Linux capabilities. This meant that processes could not do any privileged operations, ones commonly associated with root.
However, a regression in Nomad 0.9.0 allows such processes to perform privileged operations that can be malicious. For example, a process can conceivably escape the chroot, kill any host process, read and manipulate any file inside the chroot, or bind to privileged ports (<1024). Some commands (e.g. mount) may block malicious operations directly, as they detect that the user is not root, but a determined attacker can circumvent this protection by performing the kernel system call directly.
This vulnerability constitutes a serious unintentional privilege grant, and Nomad 0.9.2 reverts to Nomad 0.8 capabilities.
It is worth noting that the exec driver is not intended to provide strong security isolation, as exec tasks can access any network services on host (including nomad agent if not configured with tls and ACL, and the cloud metadata endpoints). Users are encouraged to use VM-based drivers (qemu) or container based drivers (e.g. docker) to enforce stricter security isolation.
Remediation
Clusters with the exec driver enabled must upgrade to 0.9.2. Only Nomad clients must be upgraded to fix the vulnerability. Alternatively, the exec driver may be disabled using the client configuration or via Sentinel in Nomad Enterprise. No workaround is present to run exec tasks safely in a 0.9.0 or 0.9.1 cluster.
To disable the exec task driver use the following configuration on every client node:
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
It was discovered that exec driver tasks run with full Linux capabilities such that processes can escalate to run as privileged root user, despite running as the Linux unprivileged user, nobody. This vulnerability affects versions 0.9.0 and 0.9.1 of Nomad, both OSS and Enterprise and was fixed in #5728.
Background
Nomad allows running various types of workloads. The exec driver runs processes in a chroot environment and a lightweight container. By default, Nomad 0.8 runs exec processes as nobody user with no Linux capabilities. This meant that processes could not do any privileged operations, ones commonly associated with root.
However, a regression in Nomad 0.9.0 allows such processes to perform privileged operations that can be malicious. For example, a process can conceivably escape the chroot, kill any host process, read and manipulate any file inside the chroot, or bind to privileged ports (<1024). Some commands (e.g. mount) may block malicious operations directly, as they detect that the user is not root, but a determined attacker can circumvent this protection by performing the kernel system call directly.
This vulnerability constitutes a serious unintentional privilege grant, and Nomad 0.9.2 reverts to Nomad 0.8 capabilities.
It is worth noting that the exec driver is not intended to provide strong security isolation, as exec tasks can access any network services on host (including nomad agent if not configured with tls and ACL, and the cloud metadata endpoints). Users are encouraged to use VM-based drivers (qemu) or container based drivers (e.g. docker) to enforce stricter security isolation.
Remediation
Clusters with the exec driver enabled must upgrade to 0.9.2. Only Nomad clients must be upgraded to fix the vulnerability. Alternatively, the exec driver may be disabled using the client configuration or via Sentinel in Nomad Enterprise. No workaround is present to run exec tasks safely in a 0.9.0 or 0.9.1 cluster.
To disable the exec task driver use the following configuration on every client node:
See the client configuration documentation for more details.
The text was updated successfully, but these errors were encountered: