From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87654C433E0 for ; Fri, 3 Jul 2020 01:00:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 626BC20723 for ; Fri, 3 Jul 2020 01:00:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593738039; bh=5gW68oWWeR/I+QEodHrrm8fmKQEGk9tk443l2sVF2Bs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=hcyaMlBARZtrd4gzpoBumL8D4ibJSQYkdSBIHWatZ43l7iQeXnd1v27dXUAL8Woq5 bA1ZlWRsgfhRc/CLOZNE11KGntskyiCIvDUsamtmpM+h6jBYv0SFVFHc0Aome187Vh RPxkZt8Gj+q/p4Ff1L0mFw+qQthz75+s1/dh4U9k= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726017AbgGCBAj (ORCPT ); Thu, 2 Jul 2020 21:00:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726323AbgGCBAi (ORCPT ); Thu, 2 Jul 2020 21:00:38 -0400 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41CF4C08C5DD for ; Thu, 2 Jul 2020 18:00:38 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id g20so25747097edm.4 for ; Thu, 02 Jul 2020 18:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xhJ/3m0KcF51XQMCDykPvx6FH+Zxv6t6Wm2boNZX4GA=; b=HRnc8Z/UWD1VH3SDqiH4lfspf3ok3r+xS7c66s+ynb3ZzlBkN2PSz5kYMKHrzl7TQ4 fZ8+IFqVBJWm7YWqXIR8IP8nkdyQC3joTYpIj49kaBTa633kHTrhJhFkqzD8TramRmM1 Yo4ZUFvd4iiBdz/qOIz2C16Di7gBSp0vYJurQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xhJ/3m0KcF51XQMCDykPvx6FH+Zxv6t6Wm2boNZX4GA=; b=DEoAD3OpqZODldnotroIR1lFoARSBB6q42iPRn5Yopvb5y40l0NxsEm7ZXdbZecEp7 1DeGYQc0o9QVmZVb1t3xDQa+kV1bF60U2jaAEkHxes+cDhFQje2slsHdW2tCGYOXgD4L hI3WnV9wKHM/5MpUtqsZGhJIvMKTXGmk1LPfN6jCvZs6HmAaqj1aGqKqpBfTK3vyqfy0 kwZSFW59eMAnX1sAouLwQS8liDo3QJGxdUfd5srF4huWMBbsIoHINJnvTPOe7LTguldQ jvUz5bAebH2fY84XG66wqWdR81fRdVMj8nl+3nXgCYJjE0Fl65AR0Bnj8WZsthvT0G40 DBOA== X-Gm-Message-State: AOAM531EPcuid3pWmhDy6jP80wmKzMf/S0EXZfYzt3wtmjjlHHVjCh/L +lk1J/bDXRiOZpOlq36rBNLaW+Uow+0= X-Google-Smtp-Source: ABdhPJx3udnva2XlcysEhawyAiRrg4+XzFXARijhnTI/dYMSaFSN5KFF2zcDATo+256dgutXLipycA== X-Received: by 2002:a05:6402:22f0:: with SMTP id dn16mr38206364edb.83.1593738036738; Thu, 02 Jul 2020 18:00:36 -0700 (PDT) Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com. [209.85.218.41]) by smtp.gmail.com with ESMTPSA id lj18sm8066188ejb.43.2020.07.02.18.00.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 18:00:36 -0700 (PDT) Received: by mail-ej1-f41.google.com with SMTP id y10so32009829eje.1 for ; Thu, 02 Jul 2020 18:00:35 -0700 (PDT) X-Received: by 2002:a2e:9c92:: with SMTP id x18mr12604594lji.70.1593738033657; Thu, 02 Jul 2020 18:00:33 -0700 (PDT) MIME-Version: 1.0 References: <20200702232638.2946421-1-keescook@chromium.org> <20200702232638.2946421-5-keescook@chromium.org> In-Reply-To: <20200702232638.2946421-5-keescook@chromium.org> From: Linus Torvalds Date: Thu, 2 Jul 2020 18:00:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/5] kprobes: Do not expose probe addresses to non-CAP_SYSLOG To: Kees Cook Cc: Dominik Czarnota , stable , Jessica Yu , Greg Kroah-Hartman , Andrew Morton , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , KP Singh , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" , Masami Hiramatsu , Jakub Kicinski , "Steven Rostedt (VMware)" , Dmitry Safonov <0x7f454c46@gmail.com>, Will Deacon , Alexey Dobriyan , Marc Zyngier , Masahiro Yamada , Al Viro , Matteo Croce , Edward Cree , Nicolas Dichtel , Alexander Lobakin , Thomas Richter , Ingo Molnar , Netdev , bpf , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Jul 2, 2020 at 4:26 PM Kees Cook wrote: > > The kprobe show() functions were using "current"'s creds instead > of the file opener's creds for kallsyms visibility. Fix to use > seq_file->file->f_cred. Side note: I have a distinct - but despite that possibly quite incorrect - memory that I've discussed with somebody several years ago about making "current_cred()" simply warn in any IO context. IOW, we could have read and write just increment/decrement a per-thread counter, and have current_cred() do a WARN_ON_ONCE() if it's called with that counter incremented. The issue of ioctl's is a bit less obvious - there are reasons to argue those should also use open-time credentials, but on the other hand I think it's reasonable to pass a file descriptor to a suid app in order for that app to do things that the normal user cannot. But read/write are dangerous because of the "it's so easy to fool suid apps to read/write stdin/stdout". So pread/pwrite/ioctl/splice etc are things that suid applications very much do on purpose to affect a file descriptor. But plain read/write are things that might be accidental and used by attack vectors. If somebody is interested in looking into things like that, it might be a good idea to have kernel threads with that counter incremented by default. Just throwing this idea out in case somebody wants to try it. It's not just "current_cred", of course. It's all the current_cred_xxx() users too. But it may be that there are a ton of false positives because maybe some code on purpose ends up doing things like just *comparing* current_cred with file->f_cred and then that would warn too. Linus