From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752514AbdKIEnt (ORCPT ); Wed, 8 Nov 2017 23:43:49 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:53664 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752005AbdKIEnr (ORCPT ); Wed, 8 Nov 2017 23:43:47 -0500 X-Google-Smtp-Source: ABhQp+R5TyHuDOEJoU45YaYkt5Pt6UWCCfK5DRKbvjzJ8gPh0W4mC7hDAIK+emGDXR2SPUqKz0/iaHf+Cc3fAEYOGXg= MIME-Version: 1.0 In-Reply-To: References: <1510050731-32446-1-git-send-email-me@tobin.cc> From: Kaiwan N Billimoria Date: Thu, 9 Nov 2017 10:13:26 +0530 Message-ID: Subject: Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl To: Linus Torvalds Cc: Laura Abbott , "Tobin C. Harding" , "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 Mailing List , 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 > But I don't know if there is anything else than the profiling code > that _really_ wants access to /proc/kallsyms in user space as a > regular user. Am unsure about this, but kprobes? (/jprobes/kretprobes), and by extension, wrappers over this infra (like SystemTap)? I (hazily) recollect a script I once wrote (years back though) that collects kernel virtual addresses off of kallsyms for the purpose of passing them to a 'helper' kernel module that uses kprobes. I realize that 'modern' kprobes exposes APIs that just require the symbolic name & that they're anyway at kernel privilege... but the point is, a usermode script was picking up and passing the kernel addresses. Also, what about kernel addresses exposed via System.map? Oh, just checked, it's root rw only.. pl ignore. > That said, that patch also fixes the /proc/kallsyms root check, in > that now you can do: > > sudo head < /proc/kallsyms > > and it still shows all zeroes - because the file was *opened* as a > normal user. That's how UNIX file access security works, and how it is > fundamentally supposed to work (ie passing a file descriptor to a sui > program doesn't magically make it gain privileges). Indeed. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kaiwan N Billimoria Subject: Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl Date: Thu, 9 Nov 2017 10:13:26 +0530 Message-ID: References: <1510050731-32446-1-git-send-email-me@tobin.cc> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Laura Abbott , "Tobin C. Harding" , "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 , To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org > But I don't know if there is anything else than the profiling code > that _really_ wants access to /proc/kallsyms in user space as a > regular user. Am unsure about this, but kprobes? (/jprobes/kretprobes), and by extension, wrappers over this infra (like SystemTap)? I (hazily) recollect a script I once wrote (years back though) that collects kernel virtual addresses off of kallsyms for the purpose of passing them to a 'helper' kernel module that uses kprobes. I realize that 'modern' kprobes exposes APIs that just require the symbolic name & that they're anyway at kernel privilege... but the point is, a usermode script was picking up and passing the kernel addresses. Also, what about kernel addresses exposed via System.map? Oh, just checked, it's root rw only.. pl ignore. > That said, that patch also fixes the /proc/kallsyms root check, in > that now you can do: > > sudo head < /proc/kallsyms > > and it still shows all zeroes - because the file was *opened* as a > normal user. That's how UNIX file access security works, and how it is > fundamentally supposed to work (ie passing a file descriptor to a sui > program doesn't magically make it gain privileges). Indeed. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <1510050731-32446-1-git-send-email-me@tobin.cc> From: Kaiwan N Billimoria Date: Thu, 9 Nov 2017 10:13:26 +0530 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl To: Linus Torvalds Cc: Laura Abbott , "Tobin C. Harding" , "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 Mailing List , Network Development , David Miller List-ID: > But I don't know if there is anything else than the profiling code > that _really_ wants access to /proc/kallsyms in user space as a > regular user. Am unsure about this, but kprobes? (/jprobes/kretprobes), and by extension, wrappers over this infra (like SystemTap)? I (hazily) recollect a script I once wrote (years back though) that collects kernel virtual addresses off of kallsyms for the purpose of passing them to a 'helper' kernel module that uses kprobes. I realize that 'modern' kprobes exposes APIs that just require the symbolic name & that they're anyway at kernel privilege... but the point is, a usermode script was picking up and passing the kernel addresses. Also, what about kernel addresses exposed via System.map? Oh, just checked, it's root rw only.. pl ignore. > That said, that patch also fixes the /proc/kallsyms root check, in > that now you can do: > > sudo head < /proc/kallsyms > > and it still shows all zeroes - because the file was *opened* as a > normal user. That's how UNIX file access security works, and how it is > fundamentally supposed to work (ie passing a file descriptor to a sui > program doesn't magically make it gain privileges). Indeed.