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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 BABCBC433ED for ; Mon, 17 May 2021 15:46:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9D6BC61184 for ; Mon, 17 May 2021 15:46:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244915AbhEQPrV (ORCPT ); Mon, 17 May 2021 11:47:21 -0400 Received: from wnew1-smtp.messagingengine.com ([64.147.123.26]:35969 "EHLO wnew1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343758AbhEQPmF (ORCPT ); Mon, 17 May 2021 11:42:05 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id 27C19273; Mon, 17 May 2021 11:40:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 17 May 2021 11:40:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho.pizza; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=wst7L607Txv7R6hkiDuGqcVCA4a 4080QIuIbxzlHCcU=; b=vdWhaeQ8Ry88uZH2ZQx7NTjdu982iHmRxpRteix8qpH q8OidQcWzX9HF68eMo5a6DuPvSLtXiz9pe1n+xpUQ/s7KyQZoV+d3JdXLgbeqbZ5 km38NOqL2Y0bvgMYBKGIZYS/Mk5M73Np2qewnaeXNMWiL/FTBtxaXN9kCnyZNGHd TBS67A8rMpZZb/gFsmHA5zjeMj4K4EK6N6X5/f2jWTTJBeJFGsgYwTRpMnl1IEjL 3Kl73TGQmgKdEhW568XKsrJ3eXd04pCCWsqbpPeIvJmfgBZ9+hS6Os8osWpbDo0y iw9gtqnPKPd4kV2VlO81LBWdEGuChuciXfpZsBvCIeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=wst7L6 07Txv7R6hkiDuGqcVCA4a4080QIuIbxzlHCcU=; b=gsOQPxbTg6IkY5X0kjex4H GYEIJDZrSrb8/WrmXu6/RhfHgoCo1jhYNxNhY5/7wnUi+hyPTf2rkQbEvzpuzlQv /g3yd3hlSKHY+/SDpY/wB+f9hZYZ63j+XGKXzci7jE1tLvEPGMvgAslxzfjI32A3 xd2JuZsZXAvZfhFIpt5ZLJYuXSy9U3rCVIJSBcvOe+wZa7qrqzRdQVOO9FksjGVE hwvHU0iSc/eH04VV0f4T3Z0qjq5CUnV09p09hsagRubYNPbjS4TzI8g+PmK1aobH bjUtnDLlb4NqQ9jvjGfR9MFnPS7UzcOKNrb2ZPS2R11gE9h15SX0ESZXnqN337bA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeihedgledvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefvhigthhho ucetnhguvghrshgvnhcuoehthigthhhosehthigthhhordhpihiiiigrqeenucggtffrrg htthgvrhhnpedttdeljeetiedthfetueevudegudfgjedvvdeifeehgfeuhfeileeihfej veduveenucffohhmrghinhepuhhrlhguvghfvghnshgvrdgtohhmnecukfhppeduvdekrd dutdejrddvgedurddukedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepthihtghhohesthihtghhohdrphhiiiiirg X-ME-Proxy: Received: from cisco (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 May 2021 11:40:25 -0400 (EDT) Date: Mon, 17 May 2021 09:40:24 -0600 From: Tycho Andersen To: Tianyin Xu Cc: Andy Lutomirski , YiFei Zhu , "containers@lists.linux.dev" , bpf , "Zhu, YiFei" , LSM List , Alexei Starovoitov , Andrea Arcangeli , "Kuo, Hsuan-Chi" , Claudio Canella , Daniel Borkmann , Daniel Gruss , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jann Horn , "Jia, Jinghao" , "Torrellas, Josep" , Kees Cook , Sargun Dhillon , Tobin Feldman-Fitzthum , Tom Hromatka , Will Drewry Subject: Re: [RFC PATCH bpf-next seccomp 00/12] eBPF seccomp filters Message-ID: <20210517154024.GE1964106@cisco> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: On Sun, May 16, 2021 at 03:38:00AM -0500, Tianyin Xu wrote: > On Sat, May 15, 2021 at 10:49 AM Andy Lutomirski wrote: > > > > On 5/10/21 10:21 PM, YiFei Zhu wrote: > > > On Mon, May 10, 2021 at 12:47 PM Andy Lutomirski wrote: > > >> On Mon, May 10, 2021 at 10:22 AM YiFei Zhu wrote: > > >>> > > >>> From: YiFei Zhu > > >>> > > >>> Based on: https://urldefense.com/v3/__https://lists.linux-foundation.org/pipermail/containers/2018-February/038571.html__;!!DZ3fjg!thbAoRgmCeWjlv0qPDndNZW1j6Y2Kl_huVyUffr4wVbISf-aUiULaWHwkKJrNJyo$ > > >>> > > >>> This patchset enables seccomp filters to be written in eBPF. > > >>> Supporting eBPF filters has been proposed a few times in the past. > > >>> The main concerns were (1) use cases and (2) security. We have > > >>> identified many use cases that can benefit from advanced eBPF > > >>> filters, such as: > > >> > > >> I haven't reviewed this carefully, but I think we need to distinguish > > >> a few things: > > >> > > >> 1. Using the eBPF *language*. > > >> > > >> 2. Allowing the use of stateful / non-pure eBPF features. > > >> > > >> 3. Allowing the eBPF programs to read the target process' memory. > > >> > > >> I'm generally in favor of (1). I'm not at all sure about (2), and I'm > > >> even less convinced by (3). > > >> > > >>> > > >>> * exec-only-once filter / apply filter after exec > > >> > > >> This is (2). I'm not sure it's a good idea. > > > > > > The basic idea is that for a container runtime it may wait to execute > > > a program in a container without that program being able to execve > > > another program, stopping any attack that involves loading another > > > binary. The container runtime can block any syscall but execve in the > > > exec-ed process by using only cBPF. > > > > > > The use case is suggested by Andrea Arcangeli and Giuseppe Scrivano. > > > @Andrea and @Giuseppe, could you clarify more in case I missed > > > something? > > > > We've discussed having a notifier-using filter be able to replace its > > filter. This would allow this and other use cases without any > > additional eBPF or cBPF code. > > > > A notifier is not always a solution (even ignoring its perf overhead). > > One problem, pointed out by Andrea Arcangeli, is that notifiers need > userspace daemons. So, it can hardly be used by daemonless container > engines like Podman. I'm not sure I buy this argument. Podman already has a conmon instance for each container, this could be a child of that conmon process, or live inside conmon itself. Tycho