Description

Installation of the kata-containers RPM does :

# Grant access to /dev/sev (and other devices) in guest
setsebool -P container_use_devices 1

This tells SELinux to allow access to all host devices to all containers, kata but also non-kata. This seriously hamper security on the host. A more fine grained approach should be used to grant access to /dev/sev to QEMU only.

Steps to reproduce

1. Install OSC 1.11.1 on OCP 4.20
2. Create KataConfig

Expected result

Arbitrary containers should not be able to access arbitrary host devices.

Actual result

Access is granted.

Impact

• Reduced security
• Bad customer impression on a product that claims improved security

Env

OCP 4.20 and up

Additional helpful info

Prompt:

What's the threat of using setsebool -P container_use_devices 1 ?

Gemini :

The Primary Threats
The "threat" isn't necessarily that the command itself is malicious, but that it removes a critical safety barrier. If a container is compromised, the risks include:

Direct Hardware Access: An attacker inside a container could interact directly with hardware. For example, they could read raw data from hard drives (bypassing the filesystem), access the GPU for crypto-mining, or interact with USB devices.

Kernel Exploitation: Many kernel vulnerabilities exist within device drivers. By allowing a container to "talk" to these drivers, you give an attacker a larger surface area to exploit the host kernel and achieve a full container escape.

Information Leakage: Access to devices like /dev/mem (though usually further restricted) or various bus interfaces can allow an attacker to sniff data moving across the host's hardware.

Persistent Compromise: An attacker with device access could potentially flash malicious firmware to hardware components, making the infection persist even if the container and host OS are reinstalled.

Claude:

Security Threats
1. Direct Hardware Access
Containers can now access raw device files like:

/dev/sda, /dev/nvme0n1 (raw disk access - can read/write any data on disk, bypassing filesystem permissions)
/dev/mem, /dev/kmem (direct kernel memory access)
/dev/tty* (terminal devices)
Character and block devices that could be exploited

2. Container Escape Potential
With device access, a compromised or malicious container could:

Read sensitive data from raw disks (passwords, keys, other containers' data)
Modify disk contents to escalate privileges
Access hardware that could be leveraged for privilege escalation
Potentially exploit kernel vulnerabilities through device drivers

3. Breaks Container Isolation
One of the core principles of containerization is isolation. Allowing device access weakens this boundary, making containers more like traditional processes than isolated environments.
4. Data Exfiltration
A container could read data from devices it shouldn't have access to, including data from other containers or the host system.