From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933894AbdKGVLE (ORCPT ); Tue, 7 Nov 2017 16:11:04 -0500 Received: from mail-io0-f174.google.com ([209.85.223.174]:56765 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753561AbdKGVLC (ORCPT ); Tue, 7 Nov 2017 16:11:02 -0500 X-Google-Smtp-Source: ABhQp+SoGRct1MYdwL3rYCp177OCVhNlbzJiZlt5zVj5QIJRUN/4q7yO+ka+/NVdSLGG5cgISms7uLtGiPvqOlfFjDs= MIME-Version: 1.0 In-Reply-To: <20171107205820.GX18478@eros> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <063D6719AE5E284EB5DD2968C1650D6DD00B3BD1@AcuExch.aculab.com> <20171107205820.GX18478@eros> From: Linus Torvalds Date: Tue, 7 Nov 2017 13:11:00 -0800 X-Google-Sender-Auth: ITAJ_ywuY3r0lnaYn1NMQ8Y0aq4 Message-ID: Subject: Re: [PATCH v4] scripts: add leaking_addresses.pl To: "Tobin C. Harding" Cc: David Laight , "kernel-hardening@lists.openwall.com" , "Jason A. Donenfeld" , "Theodore Ts'o" , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , "linux-kernel@vger.kernel.org" , Network Development , David Miller Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 7, 2017 at 12:58 PM, Tobin C. Harding wrote: > > Interesting idea. Isn't the same outcome already achieved with > dmesg_restrict. I appreciate that this does beg the question 'why are we > scanning dmesg then?' dmesg_restrict is even more asinine than kptr_restrict. It's a completely idiotic flag, only useful for distributions that then also refuse to show system journals to regular users. And such distributions are garbage, since that also effectively means that users can't sanely make bug reports etc. In other words, the whole 'dmesg_restrict' is the _classic_ case of so-called "security" people who make bad decisions, and play security theater. This is exactly the kind of crap that the grsecurity people came up with, and I'm sorry it was ever back-ported into the mainline kernel, because it's f*cking retarded. I often wish that security people used their brains more than they actually seem to do. Because a lot of them don't actually seem to ever look at the big picture, and they do these kinds of security theater garbage patches that don't actually help anything what-so-ever, but make people say "that's good security". And yes, the same would _very_ much be true of anything that just hides the pointers from users when they read dmesg. It wouldn't be sufficient to change the kernel, you also would have to change every single program that implements system logging, and once you did that, you'd have screwed up system debuggability. So really, people - start thinking critically about security. That VERY MUCH also means starting to thinking critically about things that people _claim_ are a security feature. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH v4] scripts: add leaking_addresses.pl Date: Tue, 7 Nov 2017 13:11:00 -0800 Message-ID: References: <1510050731-32446-1-git-send-email-me@tobin.cc> <063D6719AE5E284EB5DD2968C1650D6DD00B3BD1@AcuExch.aculab.com> <20171107205820.GX18478@eros> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: David Laight , "kernel-hardening@lists.openwall.com" , "Jason A. Donenfeld" , "Theodore Ts'o" , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , To: "Tobin C. Harding" Return-path: In-Reply-To: <20171107205820.GX18478@eros> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, Nov 7, 2017 at 12:58 PM, Tobin C. Harding wrote: > > Interesting idea. Isn't the same outcome already achieved with > dmesg_restrict. I appreciate that this does beg the question 'why are we > scanning dmesg then?' dmesg_restrict is even more asinine than kptr_restrict. It's a completely idiotic flag, only useful for distributions that then also refuse to show system journals to regular users. And such distributions are garbage, since that also effectively means that users can't sanely make bug reports etc. In other words, the whole 'dmesg_restrict' is the _classic_ case of so-called "security" people who make bad decisions, and play security theater. This is exactly the kind of crap that the grsecurity people came up with, and I'm sorry it was ever back-ported into the mainline kernel, because it's f*cking retarded. I often wish that security people used their brains more than they actually seem to do. Because a lot of them don't actually seem to ever look at the big picture, and they do these kinds of security theater garbage patches that don't actually help anything what-so-ever, but make people say "that's good security". And yes, the same would _very_ much be true of anything that just hides the pointers from users when they read dmesg. It wouldn't be sufficient to change the kernel, you also would have to change every single program that implements system logging, and once you did that, you'd have screwed up system debuggability. So really, people - start thinking critically about security. That VERY MUCH also means starting to thinking critically about things that people _claim_ are a security feature. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Sender: linus971@gmail.com In-Reply-To: <20171107205820.GX18478@eros> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <063D6719AE5E284EB5DD2968C1650D6DD00B3BD1@AcuExch.aculab.com> <20171107205820.GX18478@eros> From: Linus Torvalds Date: Tue, 7 Nov 2017 13:11:00 -0800 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH v4] scripts: add leaking_addresses.pl To: "Tobin C. Harding" Cc: David Laight , "kernel-hardening@lists.openwall.com" , "Jason A. Donenfeld" , Theodore Ts'o , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , "linux-kernel@vger.kernel.org" , Network Development , David Miller List-ID: On Tue, Nov 7, 2017 at 12:58 PM, Tobin C. Harding wrote: > > Interesting idea. Isn't the same outcome already achieved with > dmesg_restrict. I appreciate that this does beg the question 'why are we > scanning dmesg then?' dmesg_restrict is even more asinine than kptr_restrict. It's a completely idiotic flag, only useful for distributions that then also refuse to show system journals to regular users. And such distributions are garbage, since that also effectively means that users can't sanely make bug reports etc. In other words, the whole 'dmesg_restrict' is the _classic_ case of so-called "security" people who make bad decisions, and play security theater. This is exactly the kind of crap that the grsecurity people came up with, and I'm sorry it was ever back-ported into the mainline kernel, because it's f*cking retarded. I often wish that security people used their brains more than they actually seem to do. Because a lot of them don't actually seem to ever look at the big picture, and they do these kinds of security theater garbage patches that don't actually help anything what-so-ever, but make people say "that's good security". And yes, the same would _very_ much be true of anything that just hides the pointers from users when they read dmesg. It wouldn't be sufficient to change the kernel, you also would have to change every single program that implements system logging, and once you did that, you'd have screwed up system debuggability. So really, people - start thinking critically about security. That VERY MUCH also means starting to thinking critically about things that people _claim_ are a security feature. Linus