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 2A30CC3A59F for ; Thu, 29 Aug 2019 16:28:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EE60423403 for ; Thu, 29 Aug 2019 16:28:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567096107; bh=0isBkftQj9Gg9hHTU78TmmFxYE1h8gyYcnugZeuoeWU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=c9lmvXS1pzEmF5L0mlLwat4zwy/N/JfE1UMKgcIC1shcYAhbOPDYbLzS3ZzScah4a FHvZNoWTGlUnrRjGsZy3tAfqh9GiIoflByPUpep9ARDKZyxACaCZH+MS+sDYiuDY6P DHP6NYtzLBYs2NnFkWlbFlxVYW5YsHz0q7t6rAqw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727731AbfH2Q20 (ORCPT ); Thu, 29 Aug 2019 12:28:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:40600 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727347AbfH2Q20 (ORCPT ); Thu, 29 Aug 2019 12:28:26 -0400 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 6320C23403 for ; Thu, 29 Aug 2019 16:28:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567096105; bh=0isBkftQj9Gg9hHTU78TmmFxYE1h8gyYcnugZeuoeWU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=wukAxiPZfDy3ZtcloWmqW3DP3qsMj7ePmtvvo298RNDdeLbjk+yDLMngxgGPkpG7c vjPBXqrWXSXrTSTm2apasNoSbqYSII8sJNLJ+d/TLdh6+maBvkzuBbiBfhlrys+I+/ kLnPGK0ahX1LZHTZVcWXA4go+SOrk1UNPGmTEQi0= Received: by mail-wm1-f45.google.com with SMTP id t17so4389797wmi.2 for ; Thu, 29 Aug 2019 09:28:25 -0700 (PDT) X-Gm-Message-State: APjAAAUhnkjUd0P/4ZujbcyrhAe+KbsP0L13SjLD5Xg3QAwaO1Hm7iI/ w49n8I+8Mn4Maf3OX4epQI0oj2MBOcGWLOzbWYZm5w== X-Google-Smtp-Source: APXvYqw4AFPdrT5RzNU6kJNbmC7DZNh9sfduGZL2/yjx0+ctJaAvdCV/NlCBgqiaCkyDGXTO5nK7NXnSodHqigUTJa8= X-Received: by 2002:a05:600c:22d7:: with SMTP id 23mr13191080wmg.0.1567096103873; Thu, 29 Aug 2019 09:28:23 -0700 (PDT) MIME-Version: 1.0 References: <20190829051253.1927291-1-ast@kernel.org> <536636ad-0baf-31e9-85fe-2591b65068df@iogearbox.net> In-Reply-To: <536636ad-0baf-31e9-85fe-2591b65068df@iogearbox.net> From: Andy Lutomirski Date: Thu, 29 Aug 2019 09:28:12 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 bpf-next 1/3] capability: introduce CAP_BPF and CAP_TRACING To: Daniel Borkmann Cc: Alexei Starovoitov , "David S. Miller" , Peter Zijlstra , Steven Rostedt , Network Development , bpf , kernel-team , Linux API Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org > On Aug 29, 2019, at 8:47 AM, Daniel Borkmann wrote= : > >> On 8/29/19 7:12 AM, Alexei Starovoitov wrote: >> [...] >> +/* >> + * CAP_BPF allows the following BPF operations: >> + * - Loading all types of BPF programs >> + * - Creating all types of BPF maps except: >> + * - stackmap that needs CAP_TRACING >> + * - devmap that needs CAP_NET_ADMIN >> + * - cpumap that needs CAP_SYS_ADMIN >> + * - Advanced verifier features >> + * - Indirect variable access >> + * - Bounded loops >> + * - BPF to BPF function calls >> + * - Scalar precision tracking >> + * - Larger complexity limits >> + * - Dead code elimination >> + * - And potentially other features >> + * - Use of pointer-to-integer conversions in BPF programs >> + * - Bypassing of speculation attack hardening measures >> + * - Loading BPF Type Format (BTF) data >> + * - Iterate system wide loaded programs, maps, BTF objects >> + * - Retrieve xlated and JITed code of BPF programs >> + * - Access maps and programs via id >> + * - Use bpf_spin_lock() helper > > This is still very wide. Consider following example: app has CAP_BPF + > CAP_NET_ADMIN. Why can't we in this case *only* allow loading networking > related [plus generic] maps and programs? If it doesn't have CAP_TRACING, > what would be a reason to allow loading it? Same vice versa. There are > some misc program types like the infraread stuff, but they could continue > to live under [CAP_BPF +] CAP_SYS_ADMIN as fallback. I think categorizing > a specific list of prog and map types might be more clear than disallowin= g > some helpers like below (e.g. why choice of bpf_probe_read() but not > bpf_probe_write_user() etc). Wow, I didn=E2=80=99t notice that bpf_probe_write_user() existed. That shou= ld need something like CAP_PTRACE or CAP_SYS_ADMIN. I'm starting to think that something like this: https://lore.kernel.org/bpf/968f3551247a43e1104b198f2e58fb0595d425e7.156504= 0372.git.luto@kernel.org/ should maybe be finished before CAP_BPF happens at all. It really looks like the bpf operations that need privilege need to get fully catalogued and dealt with rather than just coming up with a new capability that covers a huge swath. (bpf_probe_write_user() is also terminally broken on architectures like s390x, but that's not really relevant right now. I'm a bit surprised it works on x86 with SMAP, though.)