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 93573C433DF for ; Fri, 3 Jul 2020 15:13:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7164220737 for ; Fri, 3 Jul 2020 15:13:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Icz9sgNv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726317AbgGCPN3 (ORCPT ); Fri, 3 Jul 2020 11:13:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726140AbgGCPN2 (ORCPT ); Fri, 3 Jul 2020 11:13:28 -0400 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA616C08C5DE for ; Fri, 3 Jul 2020 08:13:27 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id p1so3489666pls.4 for ; Fri, 03 Jul 2020 08:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=f9QVB5RC/+nRHe4+ZctWFco2K4WItpSZAlqb2p+cews=; b=Icz9sgNvxcWFuhBYB0YeBdhBi2CejbD8M+/dpJjsCSxzglKvoyeolYtXX6QUKWs23q kIzWD0TIv+eChFkgz3ZVB3evXDiVJfoJRMgwEvI53XNGkTJOW0FGlZuPKyjsTDchykVZ pQ+cWY05WljFot57kPZ9rjhamkIMTkaeqr2WY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f9QVB5RC/+nRHe4+ZctWFco2K4WItpSZAlqb2p+cews=; b=bQ97dDTe+rrmvRzxE4nJMGjBtofuRdyYIqlE3sNWzBEsnln9er6vVJk45XWyr2AJ1K 80MGLYkq+epqFcWd/9m7g/sbI9M+lpVZwW5QLRpS94JoEvg64jNQ/YdKlWss6S0FLg+N GqEeWbIBwCeNWOdCpkMybuGqyeaKW0CWlFOhWDyoo4DCxj5G4FiK7e33E0b4OePpkt7P 3vrhBj3xrxGTYa1/ALc0k1YaLcsY4dekwwOZWjCO+hghcfy5awngrLfqGQbhI7AlsAAb dxyoZdigxeYZoOTyE1qSnJXGmB2QBOo5Wc0HJ59PHuD1XDQOjIeUvwOVMV71+yHF4Z+i 6ksQ== X-Gm-Message-State: AOAM5336hoIPHiu7ttaXqkts7uWmQJ/J56GJmDtFMFvp0P7Tps0wT6/M Aih9/AKQnvNQ9GSU7mobab9cIA== X-Google-Smtp-Source: ABdhPJy1mHH6GBElAbdYB6aP9+yvHXEZTRhHh+TpVvCFVz/U4Q5Tvvqgs9q7O2KtkqlNf3AFhPyPzQ== X-Received: by 2002:a17:90b:213:: with SMTP id fy19mr37426487pjb.41.1593789207248; Fri, 03 Jul 2020 08:13:27 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id v15sm11875900pgo.15.2020.07.03.08.13.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jul 2020 08:13:25 -0700 (PDT) Date: Fri, 3 Jul 2020 08:13:24 -0700 From: Kees Cook To: Linus Torvalds 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 Subject: Re: [PATCH 4/5] kprobes: Do not expose probe addresses to non-CAP_SYSLOG Message-ID: <202007021815.97C76C192@keescook> References: <20200702232638.2946421-1-keescook@chromium.org> <20200702232638.2946421-5-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 02, 2020 at 06:00:17PM -0700, Linus Torvalds wrote: > 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. That does sound familiar. I can't find a thread on it, but my search abilities are poor. :) So an increment/decrement in all the IO-related syscalls, or were you thinking of some other location? > 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. So probably just start with read/write and tighten it over time, if we find other clear places, leaving ioctl/pread/pwrite/splice alone. > 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 > > 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. Yeah ... and I think the kthread test should answer that question. -- Kees Cook