---
title: "Disallow Capabilities"
url: https://docs.nirmata.io/docs/policy-sets/podsecurity/baseline/disallow-capabilities/
---


### Description
Adding additional capabilities beyond those listed below must be disallowed.

**Restricted Fields**
* spec.containers[*].securityContext.capabilities.add
* spec.initContainers[*].securityContext.capabilities.add
* spec.ephemeralContainers[*].securityContext.capabilities.add

**Allowed Values**
* `Undefined/nil`: No capability is assigned

* `AUDIT_WRITE`:  Allows writing records to the kernel auditing log. This is used for logging security-related events and auditing system activity

* `CHOWN`: Permits the process to change the owner and group of files arbitrarily

* `DAC_OVERRIDE`: Enables the process to bypass file read, write, and execute permission checks (DAC: Discretionary Access Control)

* `FOWNER`: Allows bypassing the permission checks for operations that normally require the process’s filesystem user ID to match the file's user 
ID. It also includes permission to set certain file attributes and ACLs (Access Control Lists)

* `FSETID`: Prevents the kernel from clearing the set-user-ID and set-group-ID mode bits when a file is modified, and allows setting the set-group-ID bit for files under specific conditions

* `KILL`: Permits bypassing the permission checks required for sending signals to processes

* `MKNOD`: Allows the creation of special device files using the mknod system call, which is usually restricted to system administrators.

* `NET_BIND_SERVICE`: Allows a process to bind to Internet domain privileged ports (port numbers less than 1024)

* `SETFCAP`: Permits a program to set the capabilities of a file

* `SETGID`: Allows arbitrary manipulation of process group IDs and the supplementary group ID list

* `SETPCAP`: Allows a process to manage and modify the capabilities of itself and other processes

* `SETUID`: Allows a user to execute a file with the file owner's permissions

* `SYS_CHROOT`: Allows the process to change its base directory to another location in the file system, effectively creating a new root directory for the process. This is used for isolating the process from the broader file system to enhance security

### Risks
The allowed capabilities in this policy are intended to balance functionality and security. However, each of these capabilities can still pose security risks if misused or exploited. You might want to use the `restricted` profile or customize the checks. Below are some additional capabilities not listed in this policy, along with their associated risks:

* `SYS_BOOT`: Allows a process to initiate a system reboot. An attacker could use this capability to cause service interruptions or system downtime.

* `SYS_MODULE`: Permits loading and unloading of kernel modules. An attacker can use this to introduce malicious modules or alter kernel behavior.

* `SYS_NICE`: Enables adjustment of process priorities and scheduling policies. Misuse of this capability might allow an attacker to degrade system performance by prioritizing their own processes over critical system tasks, potentially causing service degradation or denial of service.

* `SYS_TIME`: Allows setting the system time and date. Manipulating the system clock could disrupt time-based security mechanisms and logging, and can lead to security vulnerabilities or incorrect system behavior.

* `SYS_PTRACE`: Grants permission to observe processes and examine their memory and gain insights into their behavior. An unauthorized user could monitor or manipulate other processes, potentially leading to data leakage or access to sensitive information.

### Kyverno Policy
Refer to the Nirmata curated policies - [disallow-capabilities.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-capabilities/disallow-capabilities.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.capabilities.add[]` field is present, **only** the values from the prescribed list make the resource to be conformant with this security control. If the `securityContext.capabilities.add[]` field is not present, then the resource is conformant by default.
```bash
securityContext:
  capabilities:
    add:
    - AUDIT_WRITE
    - CHOWN
    - DAC_OVERRIDE
    - FOWNER
    - FSETID
    - KILL
    - MKNOD
    - NET_BIND_SERVICE
    - SETFCAP
    - SETGID
    - SETPCAP
    - SETUID
    - SYS_CHROOT
```

#### Resource Example
Below is a `Deployment` resource example where `securityContext.capabilities.add` for both containers is from the allowed list of capabilities.
```bash
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gooddeployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: container01
        image: dummyimagename
        securityContext:
          capabilities:
            add:
            - DAC_OVERRIDE
      - name: container02
        image: dummyimagename
        securityContext:
          capabilities:
            add:
            - SETGID
```text