linux-kernel - Re: Bugs involving maliciously crafted file system

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 May 2018 13:51:44 -0700
From:   Matthew Garrett <mjg59@...gle.com>
To:     david@...morbit.com
Cc:     "Theodore Ts'o" <tytso@....edu>, sandeen@...deen.net,
        ebiggers3@...il.com, darrick.wong@...cle.com, bfoster@...hat.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-xfs@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: Bugs involving maliciously crafted file system

On Wed, May 30, 2018 at 1:42 PM Dave Chinner <david@...morbit.com> 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?

You're not wrong, but we haven't considered root to be fundamentally
trustworthy for years - there are multiple kernel features that can be
configured such that root is no longer able to do certain things (the
one-way trap for requiring module signatures is the most obvious, but
IMA in appraisal mode will also restrict root), and as a result it's
not reasonable to be worried only about users - it's also necessary to
prevent root form being able to deliberately mount a filesystem that
results in arbitrary code execution in the kernel.