linux-kernel - Re: 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-prev] [day] [month] [year] [list]

Date:   Thu, 26 May 2022 23:09:52 +1000
From:   Aleksa Sarai <cyphar@...har.com>
To:     Simon Ser <contact@...rsion.fr>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: procfs: open("/proc/self/fd/...") allows bypassing O_RDONLY

On 2022-05-12, Simon Ser <contact@...rsion.fr> 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/>

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)