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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ