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.8 required=3.0 tests=BAYES_00,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 3CC17C4708D for ; Fri, 28 May 2021 15:54:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1BB6D613AB for ; Fri, 28 May 2021 15:54:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236213AbhE1Pz4 (ORCPT ); Fri, 28 May 2021 11:55:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234326AbhE1Pzx (ORCPT ); Fri, 28 May 2021 11:55:53 -0400 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0814DC06174A for ; Fri, 28 May 2021 08:54:18 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id o5so5410633edc.5 for ; Fri, 28 May 2021 08:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BgRoFUGRATJe+d8KSXVyiLV5UyX1useCAnQIlrvAaWU=; b=TSht/y42/eGQLtb/KSdYcn4N3XmFXll94R1oB2MfApoaXw3sgup1BUAL8bFPptnNp1 506mPb4KCAqcczfb4gyAYgHNbaFiTowloszPrFxC10pukgPD9TsBVa1ogMg/pt0GcUMT WS0rwDK/OKjyGJUeQmgD11ufp+b/bI1/z0GcQU13gWh9uzyNsvXCG+qHGb2bZeatOIPE ESqeyBp+Xs1/VOuIpz971XND8D3kjYaNUE8SN/xBOZEhe3+tztdp74dPdfm6fqekcduV fAtRYr9pMMX5CugO/b50XxX14rF5UEoo4Q8vcER/Ejhlf+EakgTyk3tbIJ2vJk0fS3cN DSbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BgRoFUGRATJe+d8KSXVyiLV5UyX1useCAnQIlrvAaWU=; b=IieBzXu4JcoiP+z0lQD9PJBDRHjV0wM157wATjcVdjdpXcM9JP4t4LLp/vSD0KgIKN 9u8Bmgbdsgv1L9cKw5Ym6p6vbGvMKsBtWBdJ+pXe8tErvSGOoiheQI6dxQkceTPlSFUG ctrqTPFVZgD7gLU/tA3z34XlMpekorY7b63RnjZ9y/HO+G1ndaUZ+Aram+LvNm6/Qlw0 vNf/HNuZ5GQUc/QXIhvy68fDXt12rfrK/EHTfuQG6lCx113g/sLMX4EW9SC0LFswc/i0 eE/FO61O7Nn2GmaPkW3PglCAayUXOB+TuHUjTDKgWrE/M8JEAA+rHUIn809tvnPuIWij Sbsg== X-Gm-Message-State: AOAM532KScbdCNr1OTmyi1Uv1mNB+3QSrdu3Ufa3NO+NK8IF928Jfpqk kgJsbhs7Fw95ucEALtV0MU3CZ8N3pzymkg2Hhey7 X-Google-Smtp-Source: ABdhPJx9lDU4bz4ZRNuGWCmsj3KypbE5i42MpDU5uXKqoLBw/jwmLUnQhhD+lDAtTdyo/XHVCMcM3JWSpnl4Jqa5QKg= X-Received: by 2002:a05:6402:35d4:: with SMTP id z20mr10534196edc.164.1622217256341; Fri, 28 May 2021 08:54:16 -0700 (PDT) MIME-Version: 1.0 References: <20210517092006.803332-1-omosnace@redhat.com> <01135120-8bf7-df2e-cff0-1d73f1f841c3@iogearbox.net> <4fee8c12-194f-3f85-e28b-f7f24ab03c91@iogearbox.net> <17eaebd3-6389-8c80-38ed-dada9d087266@iogearbox.net> In-Reply-To: <17eaebd3-6389-8c80-38ed-dada9d087266@iogearbox.net> From: Paul Moore Date: Fri, 28 May 2021 11:54:05 -0400 Message-ID: Subject: Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks To: Daniel Borkmann Cc: Ondrej Mosnacek , Linux Security Module list , James Morris , Steven Rostedt , Ingo Molnar , Stephen Smalley , SElinux list , linuxppc-dev@lists.ozlabs.org, Linux FS Devel , bpf , network dev , Linux kernel mailing list , Casey Schaufler , Jiri Olsa , andrii.nakryiko@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 28, 2021 at 10:43 AM Daniel Borkmann wrote: > On 5/28/21 3:42 PM, Ondrej Mosnacek wrote: > > (I'm off work today and plan to reply also to Paul's comments next > > week, but for now let me at least share a couple quick thoughts on > > Daniel's patch.) Oooh, I sense some disagreement brewing :) > > On Fri, May 28, 2021 at 11:56 AM Daniel Borkmann wrote: > >> On 5/28/21 9:09 AM, Daniel Borkmann wrote: > >>> On 5/28/21 3:37 AM, Paul Moore wrote: > >>>> On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote: ... > >> Ondrej / Paul / Jiri: at least for the BPF tracing case specifically (I haven't looked > >> at the rest but it's also kind of independent), the attached fix should address both > >> reported issues, please take a look & test. > > > > Thanks, I like this solution, although there are a few gotchas: > > > > 1. This patch creates a slight "regression" in that if someone flips > > the Lockdown LSM into lockdown mode on runtime, existing (already > > loaded) BPF programs will still be able to call the > > confidentiality-breaching helpers, while before the lockdown would > > apply also to them. Personally, I don't think it's a big deal (and I > > bet there are other existing cases where some handle kept from before > > lockdown could leak data), but I wanted to mention it in case someone > > thinks the opposite. > > Yes, right, though this is nothing new either in the sense that there are > plenty of other cases with security_locked_down() that operate this way > e.g. take the open_kcore() for /proc/kcore access or the module_sig_check() > for mod signatures just to pick some random ones, same approach where the > enforcement is happen at open/load time. Another, yes, this is not really a good thing to do. Also, just because there are other places that don't really do The Right Thing doesn't mean that it is okay to also not do The Right Thing here. It's basically the two-wrongs-don't-make-a-right issue applied to kernel code. -- paul moore www.paul-moore.com 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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 39B0AC4708C for ; Fri, 28 May 2021 15:54:51 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 9183F613B6 for ; Fri, 28 May 2021 15:54:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9183F613B6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paul-moore.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Fs8QK0gryz309y for ; Sat, 29 May 2021 01:54:49 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=paul-moore-com.20150623.gappssmtp.com header.i=@paul-moore-com.20150623.gappssmtp.com header.a=rsa-sha256 header.s=20150623 header.b=TSht/y42; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=paul-moore.com (client-ip=2a00:1450:4864:20::52c; helo=mail-ed1-x52c.google.com; envelope-from=paul@paul-moore.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=paul-moore-com.20150623.gappssmtp.com header.i=@paul-moore-com.20150623.gappssmtp.com header.a=rsa-sha256 header.s=20150623 header.b=TSht/y42; dkim-atps=neutral Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Fs8Pp0Lggz2xxk for ; Sat, 29 May 2021 01:54:20 +1000 (AEST) Received: by mail-ed1-x52c.google.com with SMTP id b17so5446756ede.0 for ; Fri, 28 May 2021 08:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BgRoFUGRATJe+d8KSXVyiLV5UyX1useCAnQIlrvAaWU=; b=TSht/y42/eGQLtb/KSdYcn4N3XmFXll94R1oB2MfApoaXw3sgup1BUAL8bFPptnNp1 506mPb4KCAqcczfb4gyAYgHNbaFiTowloszPrFxC10pukgPD9TsBVa1ogMg/pt0GcUMT WS0rwDK/OKjyGJUeQmgD11ufp+b/bI1/z0GcQU13gWh9uzyNsvXCG+qHGb2bZeatOIPE ESqeyBp+Xs1/VOuIpz971XND8D3kjYaNUE8SN/xBOZEhe3+tztdp74dPdfm6fqekcduV fAtRYr9pMMX5CugO/b50XxX14rF5UEoo4Q8vcER/Ejhlf+EakgTyk3tbIJ2vJk0fS3cN DSbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BgRoFUGRATJe+d8KSXVyiLV5UyX1useCAnQIlrvAaWU=; b=bto1ZsZjSaIfVMqmg8BxpG/A9rklKBJWGjrE1tsA1c0DtSdPZke+PPIRGrRegdXfcm LR7mj2eVyx9fOFXQW8DzsBamrCGIo6AJ1Woza89dzsKjx5H/U4AlgRr0+T7SSDA2UM5j niHv4iAxyR4bLVeU01kGurWGy/s7OnFUCXV3wyC9mespvCG51TnRuR22kh3wpfYR4zd0 obM/ztPQG/iU+FAMtMuhPTmexli73zHUOQj0zE+lsMlVJ1taef4vj5rbTlAv4tHEbG/4 E0NGFWjzRrtYRbrFWltwClgdY0VT3hmMzm4R+ntNEH7bMEtsEAqRAF8h9IPsP3kx/7tM 7hZw== X-Gm-Message-State: AOAM533sjoBbfIUN5uLtRUYU7j5+GE9YhAm7qlshT6JBKXTvw0mW9aLX S1wPJjQVSGpHeGXMZ0fuctLwFVkV1Tn0d/73N8N+ X-Google-Smtp-Source: ABdhPJx9lDU4bz4ZRNuGWCmsj3KypbE5i42MpDU5uXKqoLBw/jwmLUnQhhD+lDAtTdyo/XHVCMcM3JWSpnl4Jqa5QKg= X-Received: by 2002:a05:6402:35d4:: with SMTP id z20mr10534196edc.164.1622217256341; Fri, 28 May 2021 08:54:16 -0700 (PDT) MIME-Version: 1.0 References: <20210517092006.803332-1-omosnace@redhat.com> <01135120-8bf7-df2e-cff0-1d73f1f841c3@iogearbox.net> <4fee8c12-194f-3f85-e28b-f7f24ab03c91@iogearbox.net> <17eaebd3-6389-8c80-38ed-dada9d087266@iogearbox.net> In-Reply-To: <17eaebd3-6389-8c80-38ed-dada9d087266@iogearbox.net> From: Paul Moore Date: Fri, 28 May 2021 11:54:05 -0400 Message-ID: Subject: Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks To: Daniel Borkmann Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jiri Olsa , SElinux list , network dev , Stephen Smalley , Ondrej Mosnacek , Steven Rostedt , James Morris , Casey Schaufler , Linux Security Module list , Ingo Molnar , Linux FS Devel , bpf , andrii.nakryiko@gmail.com, linuxppc-dev@lists.ozlabs.org, Linux kernel mailing list Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, May 28, 2021 at 10:43 AM Daniel Borkmann wrote: > On 5/28/21 3:42 PM, Ondrej Mosnacek wrote: > > (I'm off work today and plan to reply also to Paul's comments next > > week, but for now let me at least share a couple quick thoughts on > > Daniel's patch.) Oooh, I sense some disagreement brewing :) > > On Fri, May 28, 2021 at 11:56 AM Daniel Borkmann wrote: > >> On 5/28/21 9:09 AM, Daniel Borkmann wrote: > >>> On 5/28/21 3:37 AM, Paul Moore wrote: > >>>> On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote: ... > >> Ondrej / Paul / Jiri: at least for the BPF tracing case specifically (I haven't looked > >> at the rest but it's also kind of independent), the attached fix should address both > >> reported issues, please take a look & test. > > > > Thanks, I like this solution, although there are a few gotchas: > > > > 1. This patch creates a slight "regression" in that if someone flips > > the Lockdown LSM into lockdown mode on runtime, existing (already > > loaded) BPF programs will still be able to call the > > confidentiality-breaching helpers, while before the lockdown would > > apply also to them. Personally, I don't think it's a big deal (and I > > bet there are other existing cases where some handle kept from before > > lockdown could leak data), but I wanted to mention it in case someone > > thinks the opposite. > > Yes, right, though this is nothing new either in the sense that there are > plenty of other cases with security_locked_down() that operate this way > e.g. take the open_kcore() for /proc/kcore access or the module_sig_check() > for mod signatures just to pick some random ones, same approach where the > enforcement is happen at open/load time. Another, yes, this is not really a good thing to do. Also, just because there are other places that don't really do The Right Thing doesn't mean that it is okay to also not do The Right Thing here. It's basically the two-wrongs-don't-make-a-right issue applied to kernel code. -- paul moore www.paul-moore.com