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 AA831C3A5A4 for ; Wed, 28 Aug 2019 06:20:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 82E802173E for ; Wed, 28 Aug 2019 06:20:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566973235; bh=Kpur9phQ2EXOoC2gEFS6X8rOZ61aH6EJmQNSMTQQzGs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=InyyIBTOKyFwC7cc5zXaXf/+3GF3zMcJq1Kj/k9GBHcC14wJcnXwBd2XMeheVbuAm zFhQs20VzkkNDIOe4kFwr2AmtJTBOcv4q0/tzkVqW6kRiwcXFf9dxl6K5FqYCnDnxj UXDTP4eyPhFGqegAcIHdJyp/3pYLc6OO4Hopf28I= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726165AbfH1GUe (ORCPT ); Wed, 28 Aug 2019 02:20:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:56310 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726216AbfH1GUe (ORCPT ); Wed, 28 Aug 2019 02:20:34 -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 C3E2223407 for ; Wed, 28 Aug 2019 06:20:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566973233; bh=Kpur9phQ2EXOoC2gEFS6X8rOZ61aH6EJmQNSMTQQzGs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WZ16+dZat8HSQqYOrpFahAQH1b6giYUMoAieo690K1+PrXgLHGCqHeWpn3xw5VZQv Wb4oSaRzkHcdxGEW+bBZD8zMj/D9WgXJBpbwWi17Sy3dYfnydPkI15kZh0eWHFKtfD Wo0hm761hBrPvQb2YjSFf8kmW8RA74jWCZ8wXI9c= Received: by mail-wm1-f45.google.com with SMTP id t6so1408500wmj.4 for ; Tue, 27 Aug 2019 23:20:32 -0700 (PDT) X-Gm-Message-State: APjAAAVf+dgt7Gi5ezW8aKoCrC/wpaeBYsGDo/Dqv0w/5vLYl6lPfC0+ J3IdX04xNWZToEw7i22d4NT/o6rVcVyOTVzKnl4LvA== X-Google-Smtp-Source: APXvYqz3bvX3jRPeqDgNi/vT7/rlVue0wfdhO4v9+En2T98E4aslyf3V6KCSsA7oQXgDYVfTVYOgsIVAIJNxL1477cY= X-Received: by 2002:a1c:c5c2:: with SMTP id v185mr2746446wmf.161.1566973231079; Tue, 27 Aug 2019 23:20:31 -0700 (PDT) MIME-Version: 1.0 References: <20190827205213.456318-1-ast@kernel.org> <20190828003447.htgzsxs5oevn3eys@ast-mbp.dhcp.thefacebook.com> <20190828044903.nv3hvinkkolnnxtv@ast-mbp.dhcp.thefacebook.com> In-Reply-To: <20190828044903.nv3hvinkkolnnxtv@ast-mbp.dhcp.thefacebook.com> From: Andy Lutomirski Date: Tue, 27 Aug 2019 23:20:19 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF To: Alexei Starovoitov Cc: Andy Lutomirski , Alexei Starovoitov , Kees Cook , LSM List , James Morris , Jann Horn , Peter Zijlstra , Masami Hiramatsu , Steven Rostedt , "David S. Miller" , Daniel Borkmann , Network Development , bpf , kernel-team , Linux API Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Tue, Aug 27, 2019 at 9:49 PM Alexei Starovoitov wrote: > > On Tue, Aug 27, 2019 at 07:00:40PM -0700, Andy Lutomirski wrote: > > > > Let me put this a bit differently. Part of the point is that > > CAP_TRACING should allow a user or program to trace without being able > > to corrupt the system. CAP_BPF as you=E2=80=99ve proposed it *can* like= ly > > crash the system. > > Really? I'm still waiting for your example where bpf+kprobe crashes the s= ystem... > That's not what I meant. bpf+kprobe causing a crash is a bug. I'm referring to a totally different issue. On my laptop: $ sudo bpftool map 48: hash name foobar flags 0x0 key 8B value 8B max_entries 64 memlock 8192B 181: lpm_trie flags 0x1 key 8B value 8B max_entries 1 memlock 4096B 182: lpm_trie flags 0x1 key 20B value 8B max_entries 1 memlock 4096B 183: lpm_trie flags 0x1 key 8B value 8B max_entries 1 memlock 4096B 184: lpm_trie flags 0x1 key 20B value 8B max_entries 1 memlock 4096B 185: lpm_trie flags 0x1 key 8B value 8B max_entries 1 memlock 4096B 186: lpm_trie flags 0x1 key 20B value 8B max_entries 1 memlock 4096B 187: lpm_trie flags 0x1 key 8B value 8B max_entries 1 memlock 4096B 188: lpm_trie flags 0x1 key 20B value 8B max_entries 1 memlock 4096B $ sudo bpftool map dump id 186 key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 value: 02 00 00 00 00 00 00 00 Found 1 element $ sudo bpftool map delete id 186 key hex 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [this worked] I don't know what my laptop was doing with map id 186 in particular, but, whatever it was, I definitely broke it. If a BPF firewall is in use on something important enough, this could easily remove connectivity from part or all of the system. Right now, this needs CAP_SYS_ADMIN. With your patch, CAP_BPF is sufficient to do this, but you *also* need CAP_BPF to trace the system using BPF. Tracing with BPF is 'safe' in the absence of bugs. Modifying other peoples' maps is not. One possible answer to this would be to limit CAP_BPF to the subset of BPF that is totaly safe in the absence of bugs (e.g. loading most program types if they don't have dangerous BPF_CALL instructions but not *_BY_ID). Another answer would be to say that CAP_BPF will not be needed by future unprivileged bpf mechanisms, and that CAP_TRACING plus unprivileged bpf will be enough to do most or all interesting BPF tracing operations. If the answer is the latter, then maybe it would make sense to try to implement some of the unprivileged bpf stuff and then to see whether CAP_BPF is still needed.