All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Eric Sandeen <sandeen@sandeen.net>,
	Eric Biggers <ebiggers3@gmail.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Brian Foster <bfoster@redhat.com>,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: Bugs involving maliciously crafted file system
Date: Thu, 24 May 2018 13:55:32 +1000	[thread overview]
Message-ID: <20180524035532.GC23861@dastard> (raw)
In-Reply-To: <20180524005906.GC3434@thunk.org>

On Wed, May 23, 2018 at 08:59:06PM -0400, Theodore Y. Ts'o wrote:
> 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.

They'll do that when we provide them with a safe, easy to use
solution to the problem. This is our problem to solve, not
blame-shift it away.

> And I'll note that Eric Beiderman just posted a patch series allowing
> unprivileged processes to mount file systems in containers.

Yup, that's to make it easy for virtual kernel filesystems to be
mounted inside containers, and to solve some of FUSEs security
issues caused by needing root permissions to mount FUSE filesystems.

Enabling unprivileged mounts requires an opt-in flag in the
filesystem fs-type definition, and we most certainly won't be
setting that flag on XFS. I also doubt it will ever get set on any
other existing block device based filesystem because of the trust
model problems it exposes.

> And remember the mantra which the containner people keep chanting.
> Containers are just as secure as VM's.   Hahahaha.....

So your solution is to have VM guests and container users spin up
sandboxed VMs to access filesystem images safely? That's not really
a practical solution. :/

> > 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.

That may be true, but it's so much better than using the kernel to
parse untrusted filesystem metadata.

> And not all file systems
> have FUSE support.

Except there is now fusefs-lkl, so all kernel filesystem are fully
accessible through FUSE.

> > 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.

Been trying to get security people to understand this for years.
I've given up because there's always some new security person who
follows The Process and simply does not understand that there is a
difference.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-05-24  3:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21 17:55 INFO: task hung in xlog_grant_head_check syzbot
2018-05-22 12:31 ` Brian Foster
2018-05-22 22:26   ` Dave Chinner
2018-05-22 22:52     ` Eric Biggers
2018-05-23  4:47       ` Dave Chinner
2018-05-23  7:44       ` Darrick J. Wong
2018-05-23 16:20         ` Eric Biggers
2018-05-23 18:01           ` Eric Sandeen
2018-05-23 23:41             ` Bugs involving maliciously crafted file system Theodore Y. Ts'o
2018-05-24  0:49               ` Dave Chinner
2018-05-24  0:59                 ` Theodore Y. Ts'o
2018-05-24  3:55                   ` Dave Chinner [this message]
2018-05-24 13:16                   ` Eric Sandeen
2018-05-30 19:41                   ` Eric W. Biederman
2018-05-30 20:51                 ` Matthew Garrett
2018-06-11 13:11                   ` Dmitry Vyukov
2018-05-26 17:12               ` Dmitry Vyukov
2018-05-26 20:24                 ` Theodore Y. Ts'o
2018-06-11 13:07                   ` Dmitry Vyukov
2018-06-11 13:33                     ` Theodore Y. Ts'o
2018-06-15  9:32                       ` Dmitry Vyukov
2018-06-11 13:20             ` INFO: task hung in xlog_grant_head_check Dmitry Vyukov
2018-06-11 14:35               ` Eric Sandeen
2018-05-23 23:35           ` Dave Chinner

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=20180524035532.GC23861@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=ebiggers3@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.