validation: check the device rules by trying them

[dangowrt]

This builds on #812 and should be read after it. It is that branch plus one commit, validation: check the device rules by trying them, which is the only part that is new here; the four commits below it are #812's and will disappear from this diff once that merges.

linux_cgroups_devices reads the configured rules back out of devices.list, which is a cgroup v1 interface. #812 skips the test on a unified hierarchy for that reason, and the wording there is careful to say that the restrictions are still applied and still enforced, by an attached BPF_CGROUP_DEVICE program in the runtimes that implement it. Only the window the test looks through is gone, not the property it is checking, so skipping it is a poor final answer. This replaces the skip with a check that works on both hierarchies.

The three rules the test already configures name no device that the bundle puts in the container, so nothing about them can be observed from the inside. Two device nodes fix that: /dev/allowed at c 10:229, which the first of those rules permits, and /dev/denied at c 10:230, which only the generator's leading deny-all covers. The rules themselves are untouched, so the cgroup v1 path reads exactly what it read before, and linux.devices entries do not become cgroup rules in any runtime I checked. On a unified hierarchy runtimetest works out what the list permits by applying the entries in the listed order, which is the one requirement the spec states about this field, and compares that with what opening each node actually does. Only EPERM means the device controller refused, and it comes back before the driver behind the node is consulted, so nothing has to be loaded for the answer to be meaningful. Devices a runtime is required to supply are skipped, because runtimes add rules of their own for those and they say nothing about the configured list.

Verified as root on a cgroup v2 host against two runtimes, both reporting ok for the allowed node and the denied node: crun 1.29.1, and uxc, the OpenWrt runtime whose cgroup v2 device support is an eBPF emulation of the cgroup v1 semantics. Two independent implementations agreeing is what makes me think the test measures the property rather than one runtime's quirk. It has not been run against runc, because the machine with the privileges to test device enforcement does not have runc on it, so I want to be explicit about that rather than leave it implied.

The reason I am reasonably confident about runc anyway, and the reason the fixture uses these particular numbers, is that runc appends its own allow rules after the ones from config.json:

// Append the default allowed devices to the end of the list.
for _, device := range defaultDevs {
	c.Resources.Devices = append(c.Resources.Devices, &device.Rule)
}

The comment on AllowedDevices concedes that this is "at the very least 'questionable' (if not outright wrong) according to the runtime-spec" and that users "cannot disable this behaviour". Those appended rules are eleven allows: c *:* m and b *:* m, which grant mknod alone, then c 1:3, c 1:8, c 1:7, c 5:0, c 1:5, c 1:9, c 136:*, c 5:2 and c 10:200. None of them grants read access to c 10:229 or c 10:230, so neither node is re-allowed behind the configured list, and the wildcard m rules mean creating both nodes still works under the leading deny-all. A fixture that denied one of the default devices instead would have failed against runc for reasons that are runc's rather than the test's, which is what these numbers avoid. If a reviewer with runc to hand finds otherwise I would very much like to know.

cmd/runtimetest/main_test.go covers the rule evaluation itself: wildcards, type mismatches, a deny that does not mention read, and a later entry overriding an earlier one.

The device-ordering question this raises is now opencontainers/runtime-spec#1321.