linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Colin Walters <walters@verbum.org>
To: Mattias Nissler <mnissler@chromium.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH] Add a "nolinks" mount option.
Date: Tue, 18 Oct 2016 11:14:24 -0400	[thread overview]
Message-ID: <1476803664.765771.759750513.10771FBF@webmail.messagingengine.com> (raw)
In-Reply-To: <CAKUbbx+Z0FCc9=GVO_zfQcEL__20zbAPs3oJG851+nieSpCTKQ@mail.gmail.com>

On Mon, Oct 17, 2016, at 09:02 AM, Mattias Nissler wrote:
> OK, no more feedback thus far. Is there generally any interest in a
> mount option to avoid path name aliasing resulting in target file
> confusion? Perhaps a version that only disables symlinks instead of
> also hard-disabling files hard-linked to multiple locations (those are
> much lower risk for the situation I care about)?

So the situation here is a (privileged) process that is trying to read/write
to a filesystem tree writable by other processes that are in a separate
security domain?

That's a classic situation that requires extreme care, and I am doubtful
that symlinks are the only issue you're facing.  For example, if this
process is also *parsing* any data there, there's another whole source
of risk.

I suspect for you it wouldn't be too hard to have a "follow untrusted
path" helper function, it's possible to implement in userspace safely
with O_NOFOLLOW etc.

Regardless too, it sounds like what you want more is a
"same filesystem" traversal (stat and compare devices). 

Or does it even need to handle full traversal?  Would it have mitigated
the security issue to fstat() any files you opened and verified they
were from the writable partition you expected?




  parent reply	other threads:[~2016-10-18 15:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-14 14:28 [RFC] [PATCH] Add a "nolinks" mount option Mattias Nissler
2016-10-14 14:55 ` Al Viro
2016-10-14 15:00   ` Al Viro
2016-10-14 15:50     ` Mattias Nissler
2016-10-14 16:22       ` Mattias Nissler
2016-10-17 13:02         ` Mattias Nissler
2016-10-17 14:14           ` Austin S. Hemmelgarn
2016-10-18 15:14           ` Colin Walters [this message]
2016-10-19 11:28             ` Mattias Nissler
2016-10-19 14:35               ` Colin Walters

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=1476803664.765771.759750513.10771FBF@webmail.messagingengine.com \
    --to=walters@verbum.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mnissler@chromium.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).