On 2022-05-12, Simon Ser <contact@xxxxxxxxxxx> wrote: > Hi all, > > I'm a user-space developer working on Wayland. Recently we've been > discussing about security considerations related to FD passing between > processes [1]. > > A Wayland compositor often needs to share read-only data with its > clients. Examples include a keyboard keymap, or a pixel format table. > The clients might be untrusted. The data sharing can happen by having > the compositor send a read-only FD (ie, a FD opened with O_RDONLY) to > clients. > > It was assumed that passing such a FD wouldn't allow Wayland clients to > write to the file. However, it was recently discovered that procfs > allows to bypass this restriction. A process can open(2) > "/proc/self/fd/<fd>" with O_RDWR, and that will return a FD suitable for > writing. This also works when running the client inside a user namespace. > A PoC is available at [2] and can be tested inside a compositor which > uses this O_RDONLY strategy (e.g. wlroots compositors). > > Question: is this intended behavior, or is this an oversight? If this is > intended behavior, what would be a good way to share a FD to another > process without allowing it to write to the underlying file? This is currently intended behaviour, but I am working on a patchset to fix it. This was originally meant to be included with openat2(2) along with some other hardenings in order to add safe O_EMPTYPATH support (as well as having the ability for you to open an O_PATH descriptor and restrict how it can be re-opened). The WIP patchset is in my repo[1]. The main issue at the moment is how to deal with directories (for parity with *at(2) semantics as well as our own sanity, using a /proc/self/fd/$n as a path component can't be blocked so there's some more access mode fiddling necessary to make this all cleaner). I should have an RFC version ready in a couple of weeks. [1]: https://github.com/cyphar/linux/tree/magiclink/main -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
