PR #26618 inhibits access to /sys/firmware preventing common device detection in 64-bit kernels (aarch64)

[hraftery]

Description

This PR inhibits access to the host's /sys/firmware from unprivileged containers. But in 64-bit builds of the Raspberry PI OS, and possibly other OS's, the information that used to be in /proc/cpuinfo is now in /sys/firmware (and symlinked into /proc/device-tree).

The following files are some of those commonly used by non-root applications to detect the device model. For an example, see rpi-ws281x.

/sys/firmware/devicetree/base/serial-number
/sys/firmware/devicetree/base/model
/sys/firmware/devicetree/base/system/linux,revision
/sys/firmware/devicetree/base/system/linux,serial

Inhibiting access to /sys/firmware prevents a lot of existing software from running in a container. A less broad restriction may be appropriate, or perhaps a capability that doesn't require full privileged access.

Steps to reproduce the issue:

1. On a Raspberry Pi 3B+
2. docker build balenalib/raspberrypi3-64-python:3.10-build
3. docker run -it <image-ID> bash
4. pip install rpi-ws281x
5. python
6. import _rpi_ws281x as ws
7. leds = ws.new_ws2811_t()
8. print (ws.ws2811_get_return_t_str(ws.ws2811_init(leds)))

Describe the results you received:

"Hardware revision is not supported"

Describe the results you expected:

"Success"

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Version:           19.03.18
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        840aacc77b6c600b3b929fe9e4d9356a322b9e5b
 Built:             Tue Jun  8 10:32:15 2021
 OS/Arch:           linux/arm64
 Experimental:      false

Server:
 Engine:
  Version:          19.03.18
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       840aacc77b6c600b3b929fe9e4d9356a322b9e5b
  Built:            Tue Jun  8 10:32:15 2021
  OS/Arch:          linux/arm64
  Experimental:     true
 containerd:
  Version:          1.2.0+unknown
  GitCommit:        
 runc:
  Version:          1.0.0-rc4+dev
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 balena-engine-init:
  Version:          0.13.0
  GitCommit:        949e6fa-dirty

Output of docker info:

Client:
 Debug Mode: false

Server:
 Containers: 21
  Running: 2
  Paused: 0
  Stopped: 19
 Images: 5
 Server Version: 19.03.18
 Storage Driver: aufs
  Root Dir: /var/lib/docker/aufs
  Backing Filesystem: extfs
  Dirs: 120
  Dirperm1 Supported: true
 Logging Driver: journald
 Cgroup Driver: systemd
 Plugins:
  Volume: local
  Network: bridge host null
  Log: journald json-file local
 Swarm: 
  NodeID: 
  Is Manager: false
  Node Address: 
 Runtimes: bare runc
 Default Runtime: runc
 Init Binary: balena-engine-init
 containerd version: 
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: 949e6fa-dirty (expected: fec3683b971d9)
 Kernel Version: 5.4.83-v8
 Operating System: balenaOS 2.80.3+rev1
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 962MiB
 Name: 15f241a
 ID: WOTW:AJV6:W24J:VF6Z:IM7E:474Z:YW3H:XYGC:U4CK:D4OJ:AH2S:OPNP
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

Happen to be using balena, but not intending for that to be relevant.

[AkihiroSuda]

Containers should not have any access to the hardware details by default.
Please bind-mount the directory when your application needs it. (EDIT: Please use docker run --security-opt systempaths=unconfined --security-opt apparmor=unconfined --user USER)

[hraftery]

bind-mount fails to do anything. There is already a tmpfs mount of /sys/firmware in the container which is empty. I thought that must have been how the inhibition was done. I haven't found any method to enable access other than to run the whole container as --privileged. I have tried bind-mount, volumes, capabilities, symbolic links and a variety of other efforts. The inhibition appears sound!

Is there a non-privileged method?

[kramarov-evg]

The same issue happens to me on Jetson hardware platform with Linux4Tegra as an OS. It has has some NVIDIA-provided packages and libs, that detect Jetson model using information under /proc/device-tree to detect which platform they run on. But since this directory is symlinked from /sys/firmware/devicetree/base, all scripts using this libs fail to start. I've found no workaround for this, like passing some flag to disable platform check, but to run container in --privileged mode. But this is not welcome, thus I'm required to modify libs sources to run them in docker.

[AkihiroSuda]

A workaround is docker run --security-opt systempaths=unconfined --security-opt apparmor=unconfined --user USER .

Specifying --user USER (or use userns-remapping mode, or rootless mode) is important for security.

Probably, we should have a new security opt like --security-opt systempaths=unmask-devicetree to unmask /sys/firmware/devicetree .

[BenjaminGrayNp1]

A workaround is docker run --security-opt systempaths=unconfined --security-opt apparmor=unconfined --user USER

For reference, this is CLI only. The systempaths=unconfined option is stripped out by the CLI before it reaches the daemon. If the daemon sees systempaths=unconfined, it will error.

For the daemon you need to set the maskedPaths and readonlyPaths to empty arrays in the config.

[razvanphp]

Is a PR welcome for fixing this?

I'm thinking of restricting the paths mentioned in the original PR, like:

1. /sys/firmware/acpi/
2. /sys/firmware/ibft/
3. /sys/firmware/efi/
4. /sys/firmware/dmi/

... which basically allows devicetree subfolder to be mounted.

Obviously a custom --security-opt systempaths=unmask-devicetree would be the best way, so people can allow this only when needed. With some guidance, I can try to contribute this change.

Thank you!
R

[AkihiroSuda]

Is a PR welcome for fixing this?

Yes, if somebody can confirm that devicetree doesn't contain sensitive information.
If it contains something sensitive, we may have to emulate the filesystem with FUSE or something.