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?
next prev 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).