criu: validate non-regular descriptor files

[rst0git]

When restore opens descriptors.json from the checkpoint image, a FIFO at this path may block the read indefinitely, so repeated restore attempts can exhaust caller threads in container runtimes. To fix this, we should open this file through the pre-opened image directory with O_PATH, verify the inode is a regular file, and reopen that handle for reading. This patch also rejects symlinks and other special files, and limits the read to 1 MiB to prevent unbounded allocations.

[kolyshkin]

So, we have the same issue when reading say config.json or state.json. Does it make sense to harden against fifos and large files in there? Does this PR make sense? I mean, are we doing this for security? If yes, how could the possible exploit look like?

[rst0git]

Does this PR make sense? I mean, are we doing this for security? If yes, how could the possible exploit look like?

We recently received a report about a similar issue with the ReadJSONFile functionality in checkpointctl, and to fix this I used Aleksa's method in runc as an example. While working on this, I noticed that we have the issue with descriptors.json. The main concern is a potential denial of service (if descriptors.json replaced by FIFO in the checkpoint, opening it may cause the container runtime to hang during restore).

In the CRIU project we also clarified that we assume all image files in the checkpoint to be authentic, confidential, and to have not been tampered with by an untrusted actor (i.e., we consider such issues as bugs): https://github.com/checkpoint-restore/criu/blob/criu-dev/Documentation/under-the-hood/security/image-security.md

we have the same issue when reading say config.json or state.json. Does it make sense to harden against fifos and large files in there?

My understanding is that, in comparison to descriptors.json, config.json and state.json are not read from the supplied checkpoint during restore, so they belong to different code paths and trust boundaries.