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]
Message-ID: <CACT4Y+bnOt5pCv5BvQ_AQHdvLSNKZSrw+w4Aa5YJRFNy4o0jww@mail.gmail.com>
Date:   Mon, 11 Jun 2018 15:11:17 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Matthew Garrett <mjg59@...gle.com>
Cc:     Dave Chinner <david@...morbit.com>,
        "Theodore Ts'o" <tytso@....edu>,
        Eric Sandeen <sandeen@...deen.net>,
        Eric Biggers <ebiggers3@...il.com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Brian Foster <bfoster@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: Bugs involving maliciously crafted file system

On Wed, May 30, 2018 at 10:51 PM, 'Matthew Garrett' via syzkaller-bugs
<syzkaller-bugs@...glegroups.com> wrote:
> 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.

FWIW, Android also does not consider root as trusted entity. It's
limited by SELinux and maybe something else. Kernel becomes the main
attack target on Android. Even if attackers get root, they still go
for kernel execution or kernel data corruption to do anything harmful.
And kernel is exploited with use-after-frees, out-of-bounds,
double-frees, etc.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ