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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 67BFFC3A5A3 for ; Wed, 28 Aug 2019 00:44:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 41C18214DA for ; Wed, 28 Aug 2019 00:44:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726095AbfH1Aoh (ORCPT ); Tue, 27 Aug 2019 20:44:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:42468 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbfH1Aog (ORCPT ); Tue, 27 Aug 2019 20:44:36 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B41A7208CB; Wed, 28 Aug 2019 00:44:34 +0000 (UTC) Date: Tue, 27 Aug 2019 20:44:33 -0400 From: Steven Rostedt To: Andy Lutomirski Cc: Alexei Starovoitov , Kees Cook , LSM List , James Morris , Jann Horn , Peter Zijlstra , Masami Hiramatsu , "David S. Miller" , Daniel Borkmann , Network Development , bpf , kernel-team , Linux API Subject: Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF Message-ID: <20190827204433.3af91faf@gandalf.local.home> In-Reply-To: References: <20190827205213.456318-1-ast@kernel.org> <20190827192144.3b38b25a@gandalf.local.home> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, 27 Aug 2019 16:34:47 -0700 Andy Lutomirski wrote: > > > CAP_TRACING does not override normal permissions on sysfs or debugfs. > > > This means that, unless a new interface for programming kprobes and > > > such is added, it does not directly allow use of kprobes. > > > > kprobes can be created in the tracefs filesystem (which is separate from > > debugfs, tracefs just gets automatically mounted > > in /sys/kernel/debug/tracing when debugfs is mounted) from the > > kprobe_events file. /sys/kernel/tracing is just the tracefs > > directory without debugfs, and was created specifically to allow > > tracing to be access without opening up the can of worms in debugfs. > > I think that, in principle, CAP_TRACING should allow this, but I'm not > sure how to achieve that. I suppose we could set up > inode_operations.permission on tracefs, but what exactly would it do? > Would it be just like generic_permission() except that it would look > at CAP_TRACING instead of CAP_DAC_OVERRIDE? That is, you can use > tracefs if you have CAP_TRACING *or* acl access? Or would it be: > > int tracing_permission(struct inode *inode, int mask) > { > if (!capable(CAP_TRACING)) > return -EPERM; > > return generic_permission(inode, mask); > } Perhaps we should make a group for it? > > Which would mean that you need ACL *and* CAP_TRACING, so > administrators would change the mode to 777. That's a bit scary. > > And this still doesn't let people even *find* tracefs, since it's > hidden in debugfs. > > So maybe make CAP_TRACING override ACLs but also add /sys/fs/tracing > and mount tracefs there, too, so that regular users can at least find > the mountpoint. I think you missed what I said. It's not hidden in /sys/kernel/debug. If you enable tracefs, you have /sys/kernel/tracing created, and is completely separate from debugfs. I only have it *also* automatically mounted to /sys/kernel/debug/tracing for backward compatibility reasons, as older versions of trace-cmd will only mount debugfs (as root), and expect to find it there. mount -t tracefs nodev /sys/kernel/tracing -- Steve > > > > > Should we allow CAP_TRACING access to /proc/kallsyms? as it is helpful > > to convert perf and trace-cmd's function pointers into names. Once you > > allow tracing of the kernel, hiding /proc/kallsyms is pretty useless. > > I think we should.