linux-kernel - Re: [RFC] [PATCH] Add a "nolinks" mount option.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Oct 2016 11:14:24 -0400
From:   Colin Walters <walters@...bum.org>
To:     Mattias Nissler <mnissler@...omium.org>,
        Al Viro <viro@...iv.linux.org.uk>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] [PATCH] Add a "nolinks" mount option.

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?