linux-kernel - Re: [PATCH v4] Add a "nosymfollow" 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 31 Jan 2020 12:51:34 +1100
From:   Aleksa Sarai <cyphar@...har.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Ross Zwisler <zwisler@...omium.org>, linux-kernel@...r.kernel.org,
        Mattias Nissler <mnissler@...omium.org>,
        Benjamin Gordon <bmgordon@...gle.com>,
        Ross Zwisler <zwisler@...gle.com>,
        Raul Rangel <rrangel@...gle.com>,
        Micah Morton <mortonm@...gle.com>,
        Dmitry Torokhov <dtor@...gle.com>, Jan Kara <jack@...e.cz>,
        David Howells <dhowells@...hat.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v4] Add a "nosymfollow" mount option.

On 2020-01-30, Matthew Wilcox <willy@...radead.org> wrote:
> On Thu, Jan 30, 2020 at 05:27:50PM -0700, Ross Zwisler wrote:
> > For mounts that have the new "nosymfollow" option, don't follow
> > symlinks when resolving paths. The new option is similar in spirit to
> > the existing "nodev", "noexec", and "nosuid" options. Various BSD
> > variants have been supporting the "nosymfollow" mount option for a
> > long time with equivalent implementations.
> > 
> > Note that symlinks may still be created on file systems mounted with
> > the "nosymfollow" option present. readlink() remains functional, so
> > user space code that is aware of symlinks can still choose to follow
> > them explicitly.
> > 
> > Setting the "nosymfollow" mount option helps prevent privileged
> > writers from modifying files unintentionally in case there is an
> > unexpected link along the accessed path. The "nosymfollow" option is
> > thus useful as a defensive measure for systems that need to deal with
> > untrusted file systems in privileged contexts.
> 
> The openat2 series was just merged yesterday which includes a
> LOOKUP_NO_SYMLINKS option.  Is this enough for your needs, or do you
> need the mount option?

I have discussed a theoretical "noxdev" mount option (which is
effectively LOOKUP_NO_XDEV) with Howells (added to Cc) in the past, and
the main argument for having a mount option is that you can apply the
protection to older programs without having to rewrite them to use
openat2(2).

However, the underlying argument for "noxdev" was that you could use it
to constrain something like "tar -xf" inside a mountpoint (which could
-- in principle -- be a bind-mount). I'm not so sure that "nosymfollow"
has similar "obviously useful" applications (though I'd be happy to be
proven wrong).

If FreeBSD also has "nosymfollow", are there many applications where it
is used over O_BENEATH (and how many would be serviced by
LOOKUP_NO_SYMLINKS)?

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)