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,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 4DBB4C3A5A3 for ; Thu, 29 Aug 2019 17:36:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 25D172189D for ; Thu, 29 Aug 2019 17:36:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567100216; bh=ea0FkmH8PXzRBW7RcDTQEVccdf8hPAz7TZuLpvzvZaI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=fuBvusCzQQJ0kSMf6ZEuTuscEQvjJOLqY4TbDlreLpfvAew9w/mOEPEOZUZwqYvF+ w3BiWjO0L4XJGp2iwNObuEYlYOFFQkCdVQ83kGrVWIp2Y18a0c+9Wc5d4aHv4d7ok2 DptbCqStn0k2G0R0LFUEcFhwOcrJX3ahSUeDz1Kw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727675AbfH2Rgz (ORCPT ); Thu, 29 Aug 2019 13:36:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:39522 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727800AbfH2Rgz (ORCPT ); Thu, 29 Aug 2019 13:36:55 -0400 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 91E8923429 for ; Thu, 29 Aug 2019 17:36:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567100213; bh=ea0FkmH8PXzRBW7RcDTQEVccdf8hPAz7TZuLpvzvZaI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IKM+nPQ+alg5O5IVfRE/2QO9Ec0GcIu8gegQg/3+boqUxCn4co39iaJ06oHWkQxvS vWx+Lu8Ru7lcoA6KM0RLotpwO2EtGh8dBFlUeXLBGnnjFLxMnTU4jYWwD5ml+o/upZ YJv/5M2koVM/zHgvNSpL6VbAuEo5Rr3UjkNsAaTY= Received: by mail-wm1-f47.google.com with SMTP id l2so4689413wmg.0 for ; Thu, 29 Aug 2019 10:36:53 -0700 (PDT) X-Gm-Message-State: APjAAAWagKY0fZHlqzo/+YvI48C0O4F/Gdp4aps1nA82crNBKVNiA2nm /YQSPvLubas1K3PkjAHZnrakdiyR/4bHiD0t7ulQ2A== X-Google-Smtp-Source: APXvYqygGVqJ1zS6mVlVm9RUh+IxDMWHbVhAGM9wKUXsszCSiT4u/WM3d1Iy9ZTHTQB+lr9p94LELbHNcWUtCs4z3mI= X-Received: by 2002:a05:600c:24cf:: with SMTP id 15mr13061992wmu.76.1567100211920; Thu, 29 Aug 2019 10:36:51 -0700 (PDT) MIME-Version: 1.0 References: <20190827205213.456318-1-ast@kernel.org> <20190828071421.GK2332@hirez.programming.kicks-ass.net> <20190828220826.nlkpp632rsomocve@ast-mbp.dhcp.thefacebook.com> <20190829093434.36540972@gandalf.local.home> <20190829172309.xd73ax4wgsjmv6zg@ast-mbp.dhcp.thefacebook.com> In-Reply-To: <20190829172309.xd73ax4wgsjmv6zg@ast-mbp.dhcp.thefacebook.com> From: Andy Lutomirski Date: Thu, 29 Aug 2019 10:36:39 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF To: Alexei Starovoitov Cc: Andy Lutomirski , Steven Rostedt , Peter Zijlstra , Alexei Starovoitov , Kees Cook , LSM List , James Morris , Jann Horn , Masami Hiramatsu , "David S. Miller" , Daniel Borkmann , Network Development , bpf , kernel-team , Linux API 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, Aug 29, 2019 at 10:23 AM Alexei Starovoitov wrote: > > On Thu, Aug 29, 2019 at 08:43:23AM -0700, Andy Lutomirski wrote: > > > > I can imagine splitting it into three capabilities: > > > > CAP_TRACE_KERNEL: learn which kernel functions are called when. This > > would allow perf profiling, for example, but not sampling of kernel > > regs. > > > > CAP_TRACE_READ_KERNEL_DATA: allow the tracing, profiling, etc features > > that can read the kernel's data. So you get function arguments via > > kprobe, kernel regs, and APIs that expose probe_kernel_read() > > > > CAP_TRACE_USER: trace unrelated user processes > > > > I'm not sure the code is written in a way that makes splitting > > CAP_TRACE_KERNEL and CAP_TRACE_READ_KERNEL_DATA, and I'm not sure that > > CAP_TRACE_KERNEL is all that useful except for plain perf record > > without CAP_TRACE_READ_KERNEL_DATA. What do you all think? I suppose > > it could also be: > > > > CAP_PROFILE_KERNEL: Use perf with events that aren't kprobes or > > tracepoints. Does not grant the ability to sample regs or the kernel > > stack directly. > > > > CAP_TRACE_KERNEL: Use all of perf, ftrace, kprobe, etc. > > > > CAP_TRACE_USER: Use all of perf with scope limited to user mode and uprobes. > > imo that makes little sense from security pov, since > such CAP_TRACE_KERNEL (ex kprobe) can trace "unrelated user process" > just as well. Yet not letting it do cleanly via uprobe. > Sort of like giving a spare key for back door of the house and > saying no, you cannot have main door key. > Not all combinations of capabilities make total sense. CAP_SETUID, for example, generally lets you get all the other capabilities. CAP_TRACE_KERNEL + CAP_TRACE_USER makes sense. CAP_TRACE_USER by itself makes sense. CAP_TRACE_READ_KERNEL_DATA without CAP_TRACE_KERNEL does not. I don't think this is a really a problem.