Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1502900imm; Wed, 23 May 2018 18:00:45 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqaQGz0JqLWAe08/SPpmeQ/CbQs5bwdn9M9Fq4t64IsmYuWisrJzgED9tRurbUb/iGUtY55 X-Received: by 2002:a65:4b02:: with SMTP id r2-v6mr3988748pgq.82.1527123645778; Wed, 23 May 2018 18:00:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527123645; cv=none; d=google.com; s=arc-20160816; b=SntoltGcqB7AEjJmKxqxoA8w81UYLHya/BA7lASbXP//82OHKdBXj5vaPuee56ZZMk gckgSSnr73VXk1wg62gaM9NVd+9FjOojaSibPramiFwYxao5Szc6SXZxM4r/MLQqdWgv 2Tvh+c3ZU4i/mfLGqBpo0JxZBccaU8Ogcze2oc+Q3Chvq6ts2bYfEGroTsYYVlmJ4p2r 8aHoR7Na1wxPrIF0nxR6CvuU5ZfjngjSFwdZzIxPckX4xOyO83ptwKvIw/hu3xjVWPkZ plKGWJohLy7aQWzrkM9AB9pZRtCj954kfi0XKys13CsBFsF6dU4QxQBu7zb6tR0u/BZz NbAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=dLwK4wXemp5nCAA4BdY2+gh5nhZ+vsJUo81l/kj2qno=; b=oafJTwsdXlL5b4WZg1Ht3lSIb76s8SA947mwJGtgVPhnuZ/3UMCrquBNQdIREuPPtT kvgSG2AdpphjmWv3sl96VzWOYQvSjLLn8unuYd7jjC/xc9bpdn4N6a8Zd184J0lMJFHF eRMh/PUkAZYWrKIntgfA+Lax48gLcxyS6F8mJHj4N4X4HXih1o5UCn5rWx5yqfVyYigS VOku19OqQ2pp5Qn3ld7SHY4IgqL67sD2/4evrRjRZRyuT5AtFTB9gzuxgn/ZK9d5tOE/ p237kCrAZvGDqmwUrVJ/XAGv+/pphidksDFdppZ4dFsfge894GG65HOSmVBBXCfJbzgN Vc1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=P+KSGtEO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l16-v6si15180149pgc.177.2018.05.23.18.00.30; Wed, 23 May 2018 18:00:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=P+KSGtEO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935286AbeEXA7O (ORCPT + 99 others); Wed, 23 May 2018 20:59:14 -0400 Received: from imap.thunk.org ([74.207.234.97]:47146 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935196AbeEXA7M (ORCPT ); Wed, 23 May 2018 20:59:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dLwK4wXemp5nCAA4BdY2+gh5nhZ+vsJUo81l/kj2qno=; b=P+KSGtEOcxhNs+CRf+RwygLtjw u+WGH61r8QJYuYnzu9mtFjB5sGZny5Jpnxew8m9FRV3E7Xm01SOTpjhR7+/LukK9o1LUs72p5P4q9 AyGEF938r9X6S78jXML9vRzbs4xEjfU8954ofwCbLn1KOZEjrUqgcptAiC1Pr4gUQMGY=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1fLeax-00060V-P7; Thu, 24 May 2018 00:59:07 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 7FAEA7A3EB3; Wed, 23 May 2018 20:59:06 -0400 (EDT) Date: Wed, 23 May 2018 20:59:06 -0400 From: "Theodore Y. Ts'o" To: Dave Chinner Cc: Eric Sandeen , Eric Biggers , "Darrick J. Wong" , Brian Foster , linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: Bugs involving maliciously crafted file system Message-ID: <20180524005906.GC3434@thunk.org> Mail-Followup-To: "Theodore Y. Ts'o" , Dave Chinner , Eric Sandeen , Eric Biggers , "Darrick J. Wong" , Brian Foster , linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, syzkaller-bugs@googlegroups.com References: <000000000000457b2d056cbb0044@google.com> <20180522123107.GC3751@bfoster.bfoster> <20180522222620.GW23861@dastard> <20180522225208.GB658@sol.localdomain> <20180523074425.GM14384@magnolia> <20180523162015.GA3684@sol.localdomain> <20180523234114.GA3434@thunk.org> <20180524004931.GB23861@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180524004931.GB23861@dastard> User-Agent: Mutt/1.9.5 (2018-04-13) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 24, 2018 at 10:49:31AM +1000, Dave Chinner wrote: > > We've learnt this lesson the hard way over and over again: don't > parse untrusted input in privileged contexts. How many times do we > have to make the same mistakes before people start to learn from > them? Good question. For how many years (or is it decades, now) has Fedora auto-mounted USB sticks? :-) Let me know when you successfully get Fedora to turn of a feature which appears to have great user appeal. And I'll note that Eric Beiderman just posted a patch series allowing unprivileged processes to mount file systems in containers. And remember the mantra which the containner people keep chanting. Containers are just as secure as VM's. Hahahaha..... > User automounting of removable storage should be done via a > privilege separation mechanism and hence avoid this whole class of > security problems. We can get this separation by using FUSE in these > situations, right? FUSE is a pretty terrible security boundary. And not all file systems have FUSE support. As I had suggested earlier, probably better to use 9P, and mount the file system in a VM. > Bugs don't have to be exploitable to be a "security issue". Detected > filesystem corruptions on a errors=panic mount, or undetected > problems that cause a x/NULL deref are still a user-triggerable > kernel crash (i.e. a DOS) and therefore considered a security > problem. I disagree here. I think it's worth it to disambiguate the two. If you have physical access to the machine, you can also apply AC mains voltage to the USB port, which will likely cause the system to crash. And at least for Chrome OS, it reboots really quickly. :-) If someone can gain control of the system so they can exfiltrate data, or be able to modify files owned as root, that's a much bigger deal that crashing the machcine in my view. - Ted