From: Pavel Machek <pavel@ucw.cz>
To: Simon Ser <contact@emersion.fr>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: procfs: open("/proc/self/fd/...") allows bypassing O_RDONLY
Date: Thu, 26 May 2022 13:08:11 +0200 [thread overview]
Message-ID: <20220526110811.GB5138@localhost> (raw)
In-Reply-To: <lGo7a4qQABKb-u_xsz6p-QtLIy2bzciBLTUJ7-ksv7ppK3mRrJhXqFmCFU4AtQf6EyrZUrYuSLDMBHEUMe5st_iT9VcRuyYPMU_jVpSzoWg=@emersion.fr>
Hi!
> 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?
Sounds like a bug. Not all world is Linux, and 'mount /proc' changing
security characteristics of fd passing is nasty and surprising.
We should not surprise people when it has security implications.
Best regards,
Pavel
--
next prev parent reply other threads:[~2022-05-26 11:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-12 10:37 procfs: open("/proc/self/fd/...") allows bypassing O_RDONLY Simon Ser
2022-05-12 12:30 ` Amir Goldstein
2022-05-12 12:38 ` Simon Ser
2022-05-13 9:36 ` Amir Goldstein
2022-05-16 7:51 ` Rasmus Villemoes
2022-05-12 12:41 ` Simon Ser
2022-05-12 12:56 ` Miklos Szeredi
2022-05-13 9:58 ` Christian Brauner
2022-05-26 13:03 ` Aleksa Sarai
2022-05-26 11:08 ` Pavel Machek [this message]
2022-05-26 13:09 ` Aleksa Sarai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220526110811.GB5138@localhost \
--to=pavel@ucw.cz \
--cc=contact@emersion.fr \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.