linux-kernel - procfs: open("/proc/self/fd/...") allows bypassing O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 May 2022 10:37:54 +0000
From:   Simon Ser <contact@...rsion.fr>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: procfs: open("/proc/self/fd/...") allows bypassing O_RDONLY

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?

Thanks,

Simon

[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/92
[2]: https://paste.sr.ht/~emersion/eac94b03f286e21f8362354b6af032291c00f8a7