linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Josh Triplett <josh@joshtriplett.org>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Jan Kara <jack@suse.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-ext4@vger.kernel.org
Subject: Re: Malicious fs images was Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps
Date: Mon, 11 Jan 2021 10:51:20 -0800	[thread overview]
Message-ID: <20210111185120.GA1164237@magnolia> (raw)
In-Reply-To: <20210110184101.GA4625@amd>

On Sun, Jan 10, 2021 at 07:41:02PM +0100, Pavel Machek wrote:
> Hi!
> 
> On Fri 2020-10-09 10:37:32, Theodore Y. Ts'o wrote:
> > On Thu, Oct 08, 2020 at 03:22:59PM -0700, Josh Triplett wrote:
> > > 
> > > I wasn't trying to make a *new* general principle or policy. I was under
> > > the impression that this *was* the policy, because it never occurred to
> > > me that it could be otherwise. It seemed like a natural aspect of the
> > > kernel/userspace boundary, to the point that the idea of it *not* being
> > > part of the kernel's stability guarantees didn't cross my mind. 
> > 
> > >From our perspective (and Darrick and I discussed this on this week's
> > ext4 video conference, so it represents the ext4 and xfs maintainer's
> > position) is that the file system format is different.  First, the
> > on-disk format is not an ABI, and it is several orders more complex
> > than a system call interface.  Second, we make no guarantees about
> > what the file system created by malicious tools will do.  For example,
> > XFS developers reject bug reports from file system fuzzers, because

My recollection of this is quite different -- sybot was sending multiple
zeroday exploits per week to the public xfs list, and nobody at Google
was helping us to /fix/ those bugs.  Each report took hours of developer
time to extract the malicious image (because Dmitry couldn't figure out
how to add that ability to syzbot) and syscall sequence from the
reproducer program, plus whatever time it took to craft a patch, test
it, and push it through review.

Dave and I complained to Dmitry about how the community had zero input
into the rate at which syzbot was allowed to look for xfs bugs.  Nobody
at Google would commit to helping fix any of the XFS bugs, and Dmitry
would not give us better choices than (a) Google AI continuing to create
zerodays and leaving the community to clean up the mess, or (b) shutting
off syzbot entirely.  At the time I said I would accept letting syzbot
run against xfs until it finds something, and turning it off until we
resolve the issue.  That wasn't acceptable, because (I guess) nobody at
Google wants to put /any/ staff time into XFS at all.

TLDR: XFS /does/ accept bug reports about fuzzed and broken images.
What we don't want is make-work Google AIs spraying zeroday code in
public places and the community developers having to clean up the mess.

> > the v5 format has CRC checks, so randomly corrupted file systems
> > won't
> > crash the kernel.  Yes, this doesn't protect against maliciously
> > created file systems where the attacker makes sure the checksums are
> > valid, but only crazy people who think containers are just as secure
> 
> Well, it is not just containers. It is also USB sticks. And people who
> believe secure boot is good idea and try to protect kernel against
> root. And crazy people who encrypt pointers in dmesg. And...
> 
> People want to use USB sticks from time to time. And while I
> understand XFS is so complex it is unsuitable for such use, I'd still
> expect bugs to be fixed there.
> 
> I hope VFAT to be safe to mount, because that is very common on USB.
> 
> I also hope ext2/3/4 is safe in that regard.

None of them are, that's why you can't mount local filesystems as an
unprivileged user by default.  At a bare minimum you'd have to audit the
fs driver code to make sure it's robust against unexpected metadata; and
since filesystems store complex relational data across multiple indices,
you end up needing to hoist a full fsck into the mount process.

Or retain the current behavior, which is to delegate the trust decision
to the sysadmin.  It's not just an XFS thing.

--D

> Anyway it would be nice to have documentation explaining this. If I'm
> wrong about VFAT being safe, it would be good to know, and I guess
> many will be surprised that XFS is using different rules.
> 
> Best regards,
> 								Pavel
> -- 
> http://www.livejournal.com/~pavelmachek



  reply	other threads:[~2021-01-11 18:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-04 23:17 Linux 5.9-rc8 Linus Torvalds
2020-10-05  8:14 ` ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps Josh Triplett
2020-10-05  9:46   ` Jan Kara
2020-10-05 10:16     ` Josh Triplett
2020-10-05 16:19       ` Jan Kara
2020-10-05 16:20   ` Jan Kara
2020-10-05 17:36   ` Darrick J. Wong
2020-10-06  0:04     ` Theodore Y. Ts'o
2020-10-06  0:32     ` Josh Triplett
2020-10-06  2:51       ` Darrick J. Wong
2020-10-06  3:18         ` Theodore Y. Ts'o
2020-10-06  5:03           ` Josh Triplett
2020-10-06  6:03             ` Josh Triplett
2020-10-06 13:35             ` Theodore Y. Ts'o
2020-10-07  8:03               ` Josh Triplett
2020-10-07 14:32                 ` Theodore Y. Ts'o
2020-10-07 20:14                   ` Josh Triplett
2020-10-08  2:10                     ` Theodore Y. Ts'o
2020-10-08 17:54                       ` Darrick J. Wong
2020-10-08 22:38                         ` Josh Triplett
2020-10-09  2:54                           ` Darrick J. Wong
2020-10-09 19:08                             ` Josh Triplett
2020-10-08 22:22                       ` Josh Triplett
2020-10-09 14:37                         ` Theodore Y. Ts'o
2020-10-09 20:30                           ` Josh Triplett
2021-01-10 18:41                           ` Malicious fs images was " Pavel Machek
2021-01-11 18:51                             ` Darrick J. Wong [this message]
2021-01-11 19:39                               ` Eric Biggers
2021-01-12 21:43                             ` Theodore Ts'o
2021-01-12 22:28                               ` Pavel Machek
2021-01-13  5:09                                 ` Theodore Ts'o
2020-10-08  2:57                     ` Andreas Dilger
2020-10-08 19:12                       ` Josh Triplett
2020-10-08 19:25                         ` Andreas Dilger
2020-10-08 22:28                           ` Josh Triplett

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=20210111185120.GA1164237@magnolia \
    --to=djwong@kernel.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=darrick.wong@oracle.com \
    --cc=jack@suse.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --subject='Re: Malicious fs images was Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps' \
    /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

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox