lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 18 Aug 2019 09:22:01 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Christoph Hellwig <hch@...radead.org>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Richard Weinberger <richard@....at>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Gao Xiang <hsiangkao@....com>, Jan Kara <jack@...e.cz>,
        Chao Yu <yuchao0@...wei.com>,
        Dave Chinner <david@...morbit.com>,
        David Sterba <dsterba@...e.cz>, Miao Xie <miaoxie@...wei.com>,
        devel <devel@...verdev.osuosl.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Darrick <darrick.wong@...cle.com>,
        Amir Goldstein <amir73il@...il.com>,
        linux-erofs <linux-erofs@...ts.ozlabs.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Li Guifu <bluce.liguifu@...wei.com>,
        Fang Wei <fangwei1@...wei.com>, Pavel Machek <pavel@...x.de>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] erofs: move erofs out of staging

On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote:
> Ted's observation was about maliciously-crafted filesystems, though, so
> integrity-only features such as metadata checksums are irrelevant.  Also the
> filesystem version is irrelevant; anything accepted by the kernel code (even if

I think allowing users to mount file systems (any of ours) without
privilege is a rather bad idea.  But that doesn't mean we should not be
as robust as we can.  Optionally disabling support for legacy formats
at compile and/or runtime is something we should actively look into as
well.

> it's legacy/deprecated) is open attack surface.
> 
> I personally consider it *mandatory* that we deal with this stuff.  But I can
> understand that we don't do a good job at it, so we shouldn't hold a new
> filesystem to an unfairly high standard relative to other filesystems...

I very much disagree.  We can't really force anyone to fix up old file
systems.  But we can very much hold new ones to (slightly) higher
standards.  Thats the only way to get the average quality up.  Some as
for things like code style - we can't magically fix up all old stuff,
but we can and usually do hold new code to higher standards.  (Often not
to standards as high as I'd personally prefer, btw).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ