V-235809

Discussion

Host devices can be directly exposed to containers at runtime. Do not directly expose host devices to containers especially for containers that are not trusted. The --device option exposes the host devices to the containers and consequently, the containers can directly access such host devices. Do not require the container to run in privileged mode to access and manipulate the host devices. By default, the container will be able to read, write and mknod these devices. Additionally, it is possible for containers to remove block devices from the host. Hence, do not expose host devices to containers directly. If at all, expose the host device to a container, use the sharing permissions appropriately: r - read only w - writable m - mknod allowed The user would not be able to use the host devices directly within the containers. By default, no host devices are exposed to containers. If the user does not provide sharing permissions and choose to expose a host device to a container, the host device would be exposed with read, write, and mknod permissions.

Check Content

Ensure host devices are not directly exposed to containers. Verify that the host device needs to be accessed from within the container and the permissions required are correctly set.

This check should be executed on all nodes in a Docker Enterprise cluster.

via CLI:

Linux: As a Docker EE Admin, execute the following command using a Universal Control Plane (UCP) client bundle:

docker ps --quiet --all | xargs docker inspect --format '{{ .Id }}: Devices={{ .HostConfig.Devices }}'

The above command lists out each device with below information:

- CgroupPermissions - For example, rwm
- PathInContainer - Device path within the container
- PathOnHost - Device path on the host

If Devices=[], or Devices=<no value>, this is not a finding. If Devices are listed and the host device is not documented and approved in the System Security Plan (SSP), this is a finding.