Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S942619AbcJSOf4 (ORCPT ); Wed, 19 Oct 2016 10:35:56 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:44409 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S942577AbcJSOfr (ORCPT ); Wed, 19 Oct 2016 10:35:47 -0400 Message-Id: <1476887746.926524.760895721.565B8D5E@webmail.messagingengine.com> X-Sasl-Enc: DH1DvoZvyMX/u2xqkIxpoI3dasZL17DtC6O/xnaxgraz 1476887746 From: Colin Walters To: Mattias Nissler Cc: Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-8de8db3f Subject: Re: [RFC] [PATCH] Add a "nolinks" mount option. Date: Wed, 19 Oct 2016 10:35:46 -0400 In-Reply-To: References: <1476455305-35554-1-git-send-email-mnissler@chromium.org> <20161014145515.GA19539@ZenIV.linux.org.uk> <20161014150017.GB19539@ZenIV.linux.org.uk> <1476803664.765771.759750513.10771FBF@webmail.messagingengine.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1660 Lines: 34 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.