From: Colin Walters <walters@verbum.org>
To: Mattias Nissler <mnissler@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH] Add a "nolinks" mount option.
Date: Wed, 19 Oct 2016 10:35:46 -0400 [thread overview]
Message-ID: <1476887746.926524.760895721.565B8D5E@webmail.messagingengine.com> (raw)
In-Reply-To: <CAKUbbxKHTQtv9Z23CkenD6FPoYzB-BWR+Rj2WV74V3qD_m2HYQ@mail.gmail.com>
On Wed, Oct 19, 2016, at 07:28 AM, Mattias Nissler wrote:
>
> Note that O_NOFOLLOW only affects the final path component. If there's
> a symlink in any of the parent directories, that'll still be traversed
> even with O_NOFOLLOW. This situation is less risky as an attacker will
> have to deal with the restriction of a fixed filename in the last
> component, but might still be exploitable.
Yeah, I meant that you'd walk the path string in userspace one by
one. That said the "fstat at the end and check device" seems a
lot better, or perhaps the mount namespaces could help.
Also, don't forget about `setfsuid()`.
> The difficulty lies in applying these measures of precaution
> system-wide. This affects most init scripts and daemons, and
> everything else that keeps state on the writable file system.
One thing to note is that at least in the freedesktop.org/GNOME etc.
side of things, we basically never have privileged processes
accessing user home directories anymore.
A good example is that GDM used to read ~username/.config/face.png
or something like that to show the user's picture on the login screen, and that was
subject to many of the same risks.
But we've basically across the board migrated to a model where
the unprivileged user session talks to privileged daemons via
a DBus (or other) API. In this case, the picture data is stored
in accountsservice. NetworkManager is another big
example of this, where e.g. WiFi credentials can be per user, and
the session passes them to the privileged daemon over DBus,
rather than having the privileged process try to parse config files
in the user's homedir. It's a lot easier to secure.
prev parent reply other threads:[~2016-10-19 14:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-14 14:28 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
2016-10-19 11:28 ` Mattias Nissler
2016-10-19 14:35 ` Colin Walters [this message]
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=1476887746.926524.760895721.565B8D5E@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
all inboxes | Powered by JetHome®