All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Add a prctl to disable ".." traversal in path resolution
Date: Wed, 11 Dec 2024 16:20:56 +0000	[thread overview]
Message-ID: <20241211162056.GF3387508@ZenIV> (raw)
In-Reply-To: <20241211.154841-core.hand.fragrant.rearview-Ajjgdy5TrwhO@cyphar.com>

On Thu, Dec 12, 2024 at 02:56:59AM +1100, Aleksa Sarai wrote:

> I think RESOLVE_BENEATH is usually more along the lines of what programs
> that are trying to restrict themselves would want (RESOLVE_IN_ROOT is
> what extraction tools want, on the other hand) as it only blocks ".."
> components that move you out of the directory you expect.
> 
> It also blocks absolute symlinks, which this proposal does nothing about
> (it even blocks magic-links, which can be an even bigger issue depending
> on what kind of program we are talking about). Alas, RESOLVE_BENEATH
> requires education...

So does this prctl, when you get to that - any references to "service manager"
that might turn it on are contradicted by the "after startup" bit in the
original posting.

IOW, I very much doubt that this problem is amenable to cargo-culting.

_If_ somebody wants to collect actual information about the use patterns,
something like prctl that would spew a stack trace when running into
.. would be an obvious approach, but I would strongly object to even
inserting a tracepoint of that sort into the mainline kernel.

  reply	other threads:[~2024-12-11 16:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-11 14:29 [RFC] Add a prctl to disable ".." traversal in path resolution Matthew Garrett
2024-12-11 15:51 ` Nicolas Frattaroli
2024-12-11 15:56 ` Aleksa Sarai
2024-12-11 16:20   ` Al Viro [this message]
2024-12-13 13:50     ` Aleksa Sarai
2024-12-13 12:55   ` Christian Brauner

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=20241211162056.GF3387508@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=cyphar@cyphar.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.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.