Replace signals!

Posted Jan 10, 2022 15:46 UTC (Mon) by nybble41 (subscriber, #55106)
In reply to: Replace signals! by NYKevin
Parent article: VSTATUS, with or without SIGINFO

> If you completely ignore it, then it doesn't do anything, so unexpectedly sending someone a signalfd accomplishes nothing from a security perspective, at least as far as I understand its semantics.

Sure, if you completely ignore the received file descriptor it doesn't do anything. The same would apply for the proposed alternative version—just holding a signalfd from another process would have no effect on either process. But generally one would expect the receiving process to *read* from the file descriptor, which for signalfd is the part that affects signal delivery.

Replace signals!

Posted Jan 10, 2022 19:18 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (1 responses)

IMHO an appropriately-designed setuid binary generally should not be in the business of accepting and reading from random file descriptors that it did not open itself. This still leaves the door open to /proc/self/fd shenanigans with inherited file descriptors, but I should hope that the binary calls fstat to confirm that it is interacting with a normal file after opening it.

The basic principle remains, however, that writing setuid binaries is an extremely fragile process and you need to be highly paranoid about absolutely everything. signalfd does not materially change that fact (especially since it's been in Linux "since kernel 2.6.22" according to signalfd(2), so the people who make these binaries really should be aware of it by now...).

Replace signals!

Posted Jan 12, 2022 2:46 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> IMHO an appropriately-designed setuid binary generally should not be in the business of accepting and reading from random file descriptors that it did not open itself.

Do you have any examples of situations where this would be an issue, apart from signalfd()? Passing file descriptors has been a standard part of various protocols for a long time now, including between processes of different privilege levels. The expectation is that reading from a file descriptor has the same effect in both the sending and receiving processes, which would imply that there is no security issue. The signalfd API breaks that expectation.

The problem isn't limited to SUID binaries. The destination could be any process running as a different user. The Wayland clipboard protocol[0], to pick one example, involves sending a file descriptor from the data source to the client obtaining the data, which is expected to read the content from the provided file descriptor after negotiating the format. These processes need not belong to the same user.

Also, /dev/stdin is a potential risk as an inherited FD which the target process does not open itself. Do SUID binaries routinely check FD 0 with fstat() before reading input to verify that it isn't a signalfd file descriptor, as opposed to a file, socket, pipe, tty, etc.—basically anything other than signalfd—which could be a reasonable and safe input source?

The behavior and permissions of a file descriptor should be determined by who opens or creates the descriptor, not who reads from it.

[0] https://wayland.freedesktop.org/docs/html/ch04.html#sect-...