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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,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 63860C3A5A1 for ; Thu, 29 Aug 2019 00:58:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 22758233FF for ; Thu, 29 Aug 2019 00:58:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="A/b0mZPC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726642AbfH2A6d (ORCPT ); Wed, 28 Aug 2019 20:58:33 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:38055 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726128AbfH2A6d (ORCPT ); Wed, 28 Aug 2019 20:58:33 -0400 Received: by mail-pg1-f195.google.com with SMTP id e11so632314pga.5 for ; Wed, 28 Aug 2019 17:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HCu9GxKna/uq7gKa9s14Sv2OjTD6YUF4iS2Qub5oG9Q=; b=A/b0mZPCuCZ0+yZ5B1ZDDH3FBsg5PH+aIZHT5TTam3sKPpZnX8Xci7elVgUzCDq2uG 5UdViTmoXZwPI6tpvtcnAPo8uI/p28yZs/CfTiKgfYRxIIF12KQ5CmPypyjZsTePlfG2 7O68jorQ7f3Ntm9mZckv98/rfACRVD79xS+psxSmnMKG5J2T2fBZ5yW9PXFpX2PaUt8n bAVXd4zrxBVr4iwA6p7UnCFsRPWbMlFJQMxIaCOj2lMJxeD62Lu+3sxqLu6NyzrymwWj 0yFkFl5QAKeP42zcKV9dJUC7Fzd9/MJQljcZpfO1l211rl9Sxq9R6aBrAsmTSxCCUmnd YgdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HCu9GxKna/uq7gKa9s14Sv2OjTD6YUF4iS2Qub5oG9Q=; b=UwvBlq7EgFGM86pegRyaTPuCSztAliOtgzDYgdykU1/MdPhXB+izxWNiL8vCZzSqgz Fl5Fh0dBu/HSp3/SyEmasSMjou56RE9oNONED5kNk4tRlrE8WmPJtfOzC0UBDuJ+TZ6f 4UE3RNVt/yrVpuXlqE0MKY5h5jSSq9nyfJCYYZWrVcF8IxaoURFWAdNTgal1HDCcBtkH DKfwOBlUZFD7a8sVzRuYhmG8lrTFat4JKjUbXLlB30OuRs9Lr6qLezHcWqFUE7HIWnl0 pV7ItbK4m2/61bObD5s40OL80LYpvCo7AOwOWx1cZhyoYQIRI0iVKUnN5spX+564QHOR sbpg== X-Gm-Message-State: APjAAAV3ft/Rpjry8Z1gwSPa9a3gcGVUSspiWuuWjs9smZ7GXeHv/yke 2Cjq3f1F4ZXdac7BjnmdK8r40w== X-Google-Smtp-Source: APXvYqwExxgHxqVlV8wOamSNqpOY8/PTR//jv1jEK9C6+n0BnhBf7kvocV2uwd5BL9TtgdeFCrm3rQ== X-Received: by 2002:a62:3145:: with SMTP id x66mr8155519pfx.186.1567040312675; Wed, 28 Aug 2019 17:58:32 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:9437:f332:3e4c:f05b? ([2601:646:c200:1ef2:9437:f332:3e4c:f05b]) by smtp.gmail.com with ESMTPSA id 4sm695379pfe.76.2019.08.28.17.58.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 17:58:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF From: Andy Lutomirski X-Mailer: iPhone Mail (16G77) In-Reply-To: <20190828233828.p7xddyw3fjzfinm6@ast-mbp.dhcp.thefacebook.com> Date: Wed, 28 Aug 2019 17:58:31 -0700 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-Transfer-Encoding: quoted-printable Message-Id: <63F74C1D-F061-41D6-A3CA-02EE640FEA8D@amacapital.net> References: <20190827205213.456318-1-ast@kernel.org> <20190828003447.htgzsxs5oevn3eys@ast-mbp.dhcp.thefacebook.com> <20190828044903.nv3hvinkkolnnxtv@ast-mbp.dhcp.thefacebook.com> <20190828233828.p7xddyw3fjzfinm6@ast-mbp.dhcp.thefacebook.com> To: Alexei Starovoitov Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org > On Aug 28, 2019, at 4:38 PM, Alexei Starovoitov wrote: >=20 >> On Tue, Aug 27, 2019 at 11:20:19PM -0700, Andy Lutomirski wrote: >> On Tue, Aug 27, 2019 at 9:49 PM Alexei Starovoitov >> wrote: >>>=20 >>>> On Tue, Aug 27, 2019 at 07:00:40PM -0700, Andy Lutomirski wrote: >>>>=20 >>>> 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. >>>=20 >>> Really? I'm still waiting for your example where bpf+kprobe crashes the s= ystem... >>>=20 >>=20 >> 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: >>=20 >> $ 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 >>=20 >> $ 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 >>=20 >> $ 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] >>=20 >> 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. >=20 > That lpm_trie is likely systemd implementing IP sandboxing. > Not sure whether it's white or black list. > Deleting an IP address from that map will either allow or disallow > network traffic. > Out of band operation on bpf map broke some bpf program. Sure. > But calling it 'breaking the system' is quite a stretch. > Calling it 'crashing the system' is plain wrong. > Yet you're generalizing this bpf map read/write as > "CAP_BPF as you=E2=80=99ve proposed it *can* likely crash the system." > This is what I have a problem with. Well, after I sent that email, firewalld on my laptop exploded and the syste= m eventually hung. I call that broken, and I really made a minimal effort h= ere to break things. >=20 > Anyway, changing gears... > Yes. I did propose to make a task with CAP_BPF to be able to > manipulate arbitrary maps in the system. > You could have said that if CAP_BPF is given to 'bpftool' > then any user will be able to mess with other maps because > bpftool is likely chmod-ed 755. > Absolutely correct! > It's not a fault of the CAP_BPF scope. > Just don't give that cap to bpftool or do different acl/chmod. I see no reason that allowing a user to use most of bpftool=E2=80=99s functi= onality necessarily needs to allow that user to corrupt the system. It obvio= usly will expand the attack surface available to that user, but that should b= e it. I=E2=80=99m trying to convince you that bpf=E2=80=99s security model can be m= ade better than what you=E2=80=99re proposing. I=E2=80=99m genuinely not try= ing to get in your way. I=E2=80=99m trying to help you improve bpf.