---
title: "Disallow Privilege Escalation"
url: https://docs.nirmata.io/docs/policy-sets/podsecurity/restricted/disallow-privilege-escalation/
---



### Description
Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed. [This is Linux only policy](https://kubernetes.io/docs/concepts/security/pod-security-standards/#os-specific-policy-controls) in v1.25+ (`spec.os.name != windows`)

**Restricted Fields**
* spec.containers[*].securityContext.allowPrivilegeEscalation
* spec.initContainers[*].securityContext.allowPrivilegeEscalation
* spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation

**Allowed Values**
* false

### Risks
The `allowPrivilegeEscalation` field controls whether processes in a container can gain more privileges than their parent process. Here are the associated risks if `allowPrivilegeEscalation` is set to `true`:

* `Root Access on Host`: When a container is run in privileged mode, the root user inside the container has the same privileges as the root user on the host system. This bypasses the usual container isolation mechanisms and can cause security risks. For instance, if an attacker gains access to a privileged container, they can compromise the entire host system.

* `Device and Capability Access`: Privileged mode lifts all limitations enforced by the device cgroup controller, allowing the container to interact with all devices on the host. This unrestricted access can be used by attackers to exploit critical system components or access sensitive data.

* `Potential Exploitation`: If an attacker manages to exploit a vulnerability within an application running inside a privileged container (e.g., a Remote Code Execution vulnerability), they can use this access to escape the container and compromise the host system.

### Kyverno Policy
Refer to the Nirmata curated policies - [disallow-privilege-escalation.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/restricted/disallow-privilege-escalation/disallow-privilege-escalation.yaml)

### References
#### Configuration Settings
The below configuration indicates that if the deployed resource contains one of `ephemeralContainers` or `initContainers` or `containers` in their `spec` field, **AND** if `securityContext.allowPrivilegeEscalation` field is present, then the only acceptable value is `false` to be conformant with this security control. If the `securityContext.allowPrivilegeEscalation` field is not present, then the resource is conformant by default.

```bash
=(ephemeralContainers):
- securityContext:
    allowPrivilegeEscalation: "false"
=(initContainers):
- securityContext:
    allowPrivilegeEscalation: "false"
containers:
- securityContext:
    allowPrivilegeEscalation: "false"
```

#### Resource Example
Below is a `Deployment` resource example where `securityContext.allowPrivilegeEscalation` is set to `false` for all `initContainers` and `containers`.

```bash
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gooddeployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      initContainers:
      - name: initcontainer01
        image: dummyimagename
        securityContext:
          allowPrivilegeEscalation: false
      - name: initcontainer02
        image: dummyimagename
        securityContext:
          allowPrivilegeEscalation: false
      containers:
      - name: container01
        image: dummyimagename
        securityContext:
          allowPrivilegeEscalation: false
      - name: container02
        image: dummyimagename
        securityContext:
          allowPrivilegeEscalation: false
```text