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 7352AC3A5A7 for ; Wed, 28 Aug 2019 02:00:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4C9E021883 for ; Wed, 28 Aug 2019 02:00:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566957656; bh=AP7WKXMKH8JAGUlgFkOqC5LEdoLGq2navL+/ozcyKKA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=HoTnM4C9RazYkfEDoFuIcbVpzf5uq4aTGbMI7gS8/6i9lJ+kLkjohqRYu89adzfbO BkmXGw/ONhgzTWmaBfT4lGbZO/9KW0RUWWXQCN4jHr2xCP+K0Ia7l7D3bX0mHjmTwH ndS4akA9KfG02rcXFf/xTZ0dD3qR90tw86KYoQDM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726363AbfH1CAz (ORCPT ); Tue, 27 Aug 2019 22:00:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:59590 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726285AbfH1CAz (ORCPT ); Tue, 27 Aug 2019 22:00:55 -0400 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 92B2E23406 for ; Wed, 28 Aug 2019 02:00:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566957653; bh=AP7WKXMKH8JAGUlgFkOqC5LEdoLGq2navL+/ozcyKKA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iRaaimshFuvzXzlPUgD9XckqINKOZ17QCJ5V164gp6IYXiuuvRXq7IsPh7Z6ymT6S cHT8FqVb5xACaMkIFmuiF5HvaOqiF361Ak9DJh7w1776AFSDhlMijXKd8j08xBXBNI akDtGBQsNMzUlh3cyuBInwV9XzvpTuJo9GGzwirg= Received: by mail-wm1-f44.google.com with SMTP id d16so1050798wme.2 for ; Tue, 27 Aug 2019 19:00:53 -0700 (PDT) X-Gm-Message-State: APjAAAUUQYPNWfGZUQwj6n6b3RYWHvDcRSeSPzD+LBtKWjnfvFsdMKUj 7h5mq/4ms+tF2U60odSr8H+NeR7ySxEOXs3tTNpBBQ== X-Google-Smtp-Source: APXvYqyk9NE8dUGaMeQjdAeSfVuPRR4HyKn+obwNgjsa5cGe+ce+JC26pUDP8pHyW/dLbAv+UggkDAJu9kj8VuL8y+o= X-Received: by 2002:a05:600c:24cf:: with SMTP id 15mr1448267wmu.76.1566957651897; Tue, 27 Aug 2019 19:00:51 -0700 (PDT) MIME-Version: 1.0 References: <20190827205213.456318-1-ast@kernel.org> <20190828003447.htgzsxs5oevn3eys@ast-mbp.dhcp.thefacebook.com> In-Reply-To: From: Andy Lutomirski Date: Tue, 27 Aug 2019 19:00:40 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF To: Andy Lutomirski Cc: Alexei Starovoitov , 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: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > On Aug 27, 2019, at 5:55 PM, Andy Lutomirski wrote: > > On Tue, Aug 27, 2019 at 5:34 PM Alexei Starovoitov > wrote: >> > From the previous discussion, you want to make progress toward solving > a lot of problems with CAP_BPF. One of them was making BPF > firewalling more generally useful. By making CAP_BPF grant the ability > to read kernel memory, you will make administrators much more nervous > to grant CAP_BPF. Similarly, and correct me if I'm wrong, most of > these capabilities are primarily or only useful for tracing, so I > don't see why users without CAP_TRACING should get them. > bpf_trace_printk(), in particular, even has "trace" in its name :) > > Also, if a task has CAP_TRACING, it's expected to be able to trace the > system -- that's the whole point. Why shouldn't it be able to use BPF > to trace the system better? 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* likely crash the system. For example, CAP_BPF allows bpf_map_get_fd_by_id() in your patch. If the system uses a BPF firewall that stores some of its rules in maps, then bpf_map_get_fd_by_id() can be used to get a writable fd to the map, which can be used to change the map, thus preventing network access. This means that no combination of CAP_TRACING and CAP_BPF ends up allowing tracing without granting the ability to reconfigure or otherwise corrupt the system.