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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 ABBB9C4346E for ; Fri, 25 Sep 2020 03:27:04 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 29C0520872 for ; Fri, 25 Sep 2020 03:27:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="cQNWEhua" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29C0520872 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=containers-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id B851886C88; Fri, 25 Sep 2020 03:27:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCcEoRD7aFTn; Fri, 25 Sep 2020 03:27:02 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by whitealder.osuosl.org (Postfix) with ESMTP id 8B9AE86B2D; Fri, 25 Sep 2020 03:27:02 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 677FEC0859; Fri, 25 Sep 2020 03:27:02 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9169DC0051 for ; Fri, 25 Sep 2020 03:27:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 8CDAE87556 for ; Fri, 25 Sep 2020 03:27:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v2Dm3hR9FOO for ; Fri, 25 Sep 2020 03:27:00 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pj1-f65.google.com (mail-pj1-f65.google.com [209.85.216.65]) by hemlock.osuosl.org (Postfix) with ESMTPS id 9D6D38754C for ; Fri, 25 Sep 2020 03:27:00 +0000 (UTC) Received: by mail-pj1-f65.google.com with SMTP id fa1so1154531pjb.0 for ; Thu, 24 Sep 2020 20:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DeK1msedXGauky3LlZFdr+n8u+1Ihl4Ki0G/c0dEbRY=; b=cQNWEhuaNcfuMfCkkICKyKMwE1l6FY6pAgtxRmC7RXPnlCJ0saei23PhAdo67xody0 RVpo2EJG4WpdQ5R8+mD+eB/MgkgQZPZufWt9hd4uz6jxYGpgabSCzyVqUGlBLvU+VxBt ZSrIa4uahkkdPSl2dtlVqAtgg+jd1CNPrWcwQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DeK1msedXGauky3LlZFdr+n8u+1Ihl4Ki0G/c0dEbRY=; b=owT884n99UaaWdPUJ5X6Hit6aZdL3QAxEPa0a04kgXs4jFJvSA2FE1MnuTHO6ibGTM JTzEa1dQmmcOgxq2+z6aBAHbSw0l462OgS23dBLg1kiZgjqUgUMP7UP7C6Bf5PPxRZP4 gptYIpNjfycmSJQavSrRhThujBZSaDgC0pJirNrSReFXYkuLQSoWmiLdcMK1NkI3/0rT EF9HV2J1GxreYKWJ6Ot4xUdxbjUgUpoStPmnqaBdz6HRMfaGHMJ2B1l94kCBdraG3+tM qDJempe+SFOjQUYsa2s8acCqp5V7HHTdn/qrTriAJbmeo7RYmoteNsZngS1LP6q89vmO 8qsQ== X-Gm-Message-State: AOAM531vFEvLkd59OLucRnkFaqRZDZKVg6qr4j1sjDKNVOwKkw5DLCYd XNA5h5s7ABbJMYlIetzQmtA2Bw== X-Google-Smtp-Source: ABdhPJymYYYGWizHsr6HmLpbJR37C6I0dl0R7R4eB+yVnjR5cxc6gFLsOvtjiudHcJH8+ojao39tog== X-Received: by 2002:a17:90b:4a0c:: with SMTP id kk12mr655501pjb.223.1601004420158; Thu, 24 Sep 2020 20:27:00 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id b10sm637973pgm.64.2020.09.24.20.26.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2020 20:26:59 -0700 (PDT) Date: Thu, 24 Sep 2020 20:26:58 -0700 From: Kees Cook To: YiFei Zhu Subject: Re: [PATCH v2 seccomp 6/6] seccomp/cache: Report cache data through /proc/pid/seccomp_cache Message-ID: <202009242021.B0FB41084@keescook> References: <202009241647.2239747F0@keescook> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: Andrea Arcangeli , Giuseppe Scrivano , Valentin Rothberg , Jann Horn , YiFei Zhu , Linux Containers , Tobin Feldman-Fitzthum , kernel list , Andy Lutomirski , Hubertus Franke , Jack Chen , Dimitrios Skarlatos , Josep Torrellas , Will Drewry , bpf , Tianyin Xu X-BeenThere: containers@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux Containers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: containers-bounces@lists.linux-foundation.org Sender: "Containers" On Thu, Sep 24, 2020 at 10:11:17PM -0500, YiFei Zhu wrote: > On Thu, Sep 24, 2020 at 6:56 PM Kees Cook wrote: > > > This file is guarded by CONFIG_PROC_SECCOMP_CACHE with a default > > The question of permissions is my central concern here: who should see > > this? Some contained processes have been intentionally blocked from > > self-introspection so even the "standard" high bar of "ptrace attach > > allowed?" can't always be sufficient. > > > > My compromise about filter visibility in the past was saying that > > CAP_SYS_ADMIN was required (see seccomp_get_filter()). I'm nervous to > > weaken this. (There is some work that hasn't been sent upstream yet that > > is looking to expose the filter _contents_ via /proc that has been > > nervous too.) > > > > Now full contents vs "allow"/"filter" are certainly different things, > > but I don't feel like I've got enough evidence to show that this > > introspection would help debugging enough to justify the partially > > imagined safety of not exposing it to potential attackers. > > Agreed. I'm inclined to make it CONFIG_DEBUG_SECCOMP_CACHE and guarded > by a CAP just to make it "debug only". Yeah; I just can't quite see what the best direction is here. I will ponder this more. As I mentioned, it does seem handy. :) > Is there something to stop a config from being enabled in an > allyesconfig? I remember seeing something like that. Else if someone > is manually selecting we can add a help text with a big banner... Yeah, allyesconfig and allmodconfig both effectively set CONFIG_COMPILE_TEST. Anyway, likely a caps test will end up being the way to do it. > > > But behavior-wise, yeah, I like it; I'm fine with human-readable and > > full AUDIT_ARCH values. (Though, as devil's advocate again, to repeat > > Jann's own words back: do we want to add this only to have a new UAPI to > > support going forward?) > > Is this something we want to keep stable? The Prime Directive of "never break userspace" is really "never break userspace in a way that someone notices". So if nothing ever parses that file, then we don't have to keep it stable, but if something does, and we change it, we have to fix it. So, a capability test means very few things will touch it, and if we decide it's not a big deal, we can relax permissions in the future. -- Kees Cook _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/containers 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.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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 C2F19C4346E for ; Fri, 25 Sep 2020 03:27:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 722ED20872 for ; Fri, 25 Sep 2020 03:27:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="cQNWEhua" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726843AbgIYD1B (ORCPT ); Thu, 24 Sep 2020 23:27:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726704AbgIYD1A (ORCPT ); Thu, 24 Sep 2020 23:27:00 -0400 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA0A8C0613CE for ; Thu, 24 Sep 2020 20:27:00 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id bw23so1147924pjb.2 for ; Thu, 24 Sep 2020 20:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DeK1msedXGauky3LlZFdr+n8u+1Ihl4Ki0G/c0dEbRY=; b=cQNWEhuaNcfuMfCkkICKyKMwE1l6FY6pAgtxRmC7RXPnlCJ0saei23PhAdo67xody0 RVpo2EJG4WpdQ5R8+mD+eB/MgkgQZPZufWt9hd4uz6jxYGpgabSCzyVqUGlBLvU+VxBt ZSrIa4uahkkdPSl2dtlVqAtgg+jd1CNPrWcwQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DeK1msedXGauky3LlZFdr+n8u+1Ihl4Ki0G/c0dEbRY=; b=tMMyi3auteqgoCny7UGUAB8WGOgjB779OnAsLDEuj9nhsmr7Kduu3hLg2Vdk31uykW xr5taIe4BGHTFDSzdDjskRQLKUmrwswXip315SKtClRT2MY8S4ZY5t5YhWKlL63Ohdj7 2LKQNyQxz/SvpYJR/xPza0MreT1hceSX132vmwDFwLNd5qFUuWn9fp4ApsWkg5JNoCM5 cbbEIXVSC9OYcuU4FO8lcXRPBmZpoRuXiyLrjnusF9+GQmW4OK1Bpu66VV4QNc7xpxZG egS9tTYEa818gD859EO7o6Vjkc6OG7gwGlN/3KwkyTaRSA7yz0TJ9z5G3BH9q5DsI8yr 4+og== X-Gm-Message-State: AOAM5312tKFGGtlCVAIWv/HUp92pbPAiiBQGCArgZwugFO2oHVq4Cx5N jevCJtqKxkgzu4ZaEs3x0dtlDg== X-Google-Smtp-Source: ABdhPJymYYYGWizHsr6HmLpbJR37C6I0dl0R7R4eB+yVnjR5cxc6gFLsOvtjiudHcJH8+ojao39tog== X-Received: by 2002:a17:90b:4a0c:: with SMTP id kk12mr655501pjb.223.1601004420158; Thu, 24 Sep 2020 20:27:00 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id b10sm637973pgm.64.2020.09.24.20.26.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2020 20:26:59 -0700 (PDT) Date: Thu, 24 Sep 2020 20:26:58 -0700 From: Kees Cook To: YiFei Zhu Cc: Linux Containers , YiFei Zhu , bpf , kernel list , Aleksa Sarai , Andrea Arcangeli , Andy Lutomirski , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jack Chen , Jann Horn , Josep Torrellas , Tianyin Xu , Tobin Feldman-Fitzthum , Tycho Andersen , Valentin Rothberg , Will Drewry Subject: Re: [PATCH v2 seccomp 6/6] seccomp/cache: Report cache data through /proc/pid/seccomp_cache Message-ID: <202009242021.B0FB41084@keescook> References: <202009241647.2239747F0@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 24, 2020 at 10:11:17PM -0500, YiFei Zhu wrote: > On Thu, Sep 24, 2020 at 6:56 PM Kees Cook wrote: > > > This file is guarded by CONFIG_PROC_SECCOMP_CACHE with a default > > The question of permissions is my central concern here: who should see > > this? Some contained processes have been intentionally blocked from > > self-introspection so even the "standard" high bar of "ptrace attach > > allowed?" can't always be sufficient. > > > > My compromise about filter visibility in the past was saying that > > CAP_SYS_ADMIN was required (see seccomp_get_filter()). I'm nervous to > > weaken this. (There is some work that hasn't been sent upstream yet that > > is looking to expose the filter _contents_ via /proc that has been > > nervous too.) > > > > Now full contents vs "allow"/"filter" are certainly different things, > > but I don't feel like I've got enough evidence to show that this > > introspection would help debugging enough to justify the partially > > imagined safety of not exposing it to potential attackers. > > Agreed. I'm inclined to make it CONFIG_DEBUG_SECCOMP_CACHE and guarded > by a CAP just to make it "debug only". Yeah; I just can't quite see what the best direction is here. I will ponder this more. As I mentioned, it does seem handy. :) > Is there something to stop a config from being enabled in an > allyesconfig? I remember seeing something like that. Else if someone > is manually selecting we can add a help text with a big banner... Yeah, allyesconfig and allmodconfig both effectively set CONFIG_COMPILE_TEST. Anyway, likely a caps test will end up being the way to do it. > > > But behavior-wise, yeah, I like it; I'm fine with human-readable and > > full AUDIT_ARCH values. (Though, as devil's advocate again, to repeat > > Jann's own words back: do we want to add this only to have a new UAPI to > > support going forward?) > > Is this something we want to keep stable? The Prime Directive of "never break userspace" is really "never break userspace in a way that someone notices". So if nothing ever parses that file, then we don't have to keep it stable, but if something does, and we change it, we have to fix it. So, a capability test means very few things will touch it, and if we decide it's not a big deal, we can relax permissions in the future. -- Kees Cook