On Thu, May 12, 2022 at 2:09 PM 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
Clients can also readlink("/proc/self/fd/<fd>") to get the path of the file
and open it from its path (if path is accessible in their mount namespace).
Would the clients typically have write permission to those files?
Do they need to?
> intended behavior, what would be a good way to share a FD to another
> process without allowing it to write to the underlying file?
>
If wayland can use a read-only bind mount to the location of the files that it
needs to share, then re-open will get EROFS.
Thanks,
Amir.
