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 310E7C3A5A4 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 00B0821883 for ; Wed, 28 Aug 2019 02:00:55 +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=nldHAXiVYjMcrYYvs0B2+ee6xYbxF90ahMGt0FC/uHfQlDCNSM2fWPcACYQxkiTaT 6WqXtNduFDrVo2IkEiw595bO61PLL3dNEBY0TTxeXxNPDBKIi2tDGoptZQdBDOpH5K 4SqYH18uCoi50yw69UD2jzOHtsaelBYD9UUwJExg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726340AbfH1CAz (ORCPT ); Tue, 27 Aug 2019 22:00:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:59578 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726127AbfH1CAz (ORCPT ); Tue, 27 Aug 2019 22:00:55 -0400 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 7EE1722CF8 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-f49.google.com with SMTP id c5so1036227wmb.5 for ; Tue, 27 Aug 2019 19:00:53 -0700 (PDT) X-Gm-Message-State: APjAAAVjdkf/Lx+MsXzjf3HFy/PLSsiVkuBsX8jZ2ZAF3tzkk0cdpZRk WOggr8Lb5MPylprD7w2VaB4ZJJ0N8mLC5lM9OKGxGA== 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: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: > 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.