[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2025-08-21.1755785636-rusted-ivory-corgi-salad-fYNRl1@cyphar.com>
Date: Fri, 22 Aug 2025 00:21:06 +1000
From: Aleksa Sarai <cyphar@...har.com>
To: Askar Safin <safinaskar@...omail.com>
Cc: Alejandro Colomar <alx@...nel.org>,
"Michael T. Kerrisk" <mtk.manpages@...il.com>, Alexander Viro <viro@...iv.linux.org.uk>,
Jan Kara <jack@...e.cz>, "G. Branden Robinson" <g.branden.robinson@...il.com>,
linux-man <linux-man@...r.kernel.org>, linux-api <linux-api@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org>,
David Howells <dhowells@...hat.com>, Christian Brauner <brauner@...nel.org>
Subject: Re: [PATCH v3 00/12] man2: document "new" mount API
On 2025-08-21, Askar Safin <safinaskar@...omail.com> wrote:
> There is one particular case when open_tree is more powerful than openat with O_PATH. open_tree supports AT_EMPTY_PATH, and openat supports nothing similar.
> This means that we can convert normal O_RDONLY file descriptor to O_PATH descriptor using open_tree! I. e.:
> rd = openat(AT_FDCWD, "/tmp/a", O_RDONLY, 0); // Regular file
> open_tree(rd, "", AT_EMPTY_PATH);
> You can achieve same effect using /proc:
> rd = openat(AT_FDCWD, "/tmp/a", O_RDONLY, 0); // Regular file
> snprintf(buf, sizeof(buf), "/proc/self/fd/%d", rd);
> openat(AT_FDCWD, buf, O_PATH, 0);
> But still I think this has security implications. This means that even if we deny access to /proc for container, it still is able to convert O_RDONLY
> descriptors to O_PATH descriptors using open_tree. I. e. this is yet another thing to think about when creating sandboxes.
> I know you delivered a talk about similar things a lot of time ago: https://lwn.net/Articles/934460/ . (I tested this.)
O_RDONLY -> O_PATH is less of an issue than the other way around. There
isn't much you can do with O_PATH that you can't do with a properly open
file (by design you actually should have strictly less privileges but
some operations are only really possible with O_PATH, but they're not
security-critical in that way).
I was working on a new patchset for resolving this issue (and adding
O_EMPTYPATH support) late last year but other things fell on my plate
and the design was quite difficult to get to a place where everyone
agreed to it.
The core issue is that we would need to block not just re-opening but
also any operation that is a write (or read) in disguise, which kind of
implies you need to have capabilities attached to file descriptors. This
is already slightly shaky ground if you look at the history of projects
like capsicum -- but also my impression was that just adding it to
"file_permission" was not sufficient, you need to put it in
"path_permission" which means we have to either bloat "struct path" or
come up with some extended structure that you need to plumb through
everywhere.
But yes, this is a thing that is still on my list of things to do, but
not in the immediate future.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
Download attachment "signature.asc" of type "application/pgp-signature" (266 bytes)
Powered by blists - more mailing lists