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_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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 E9733C433E2 for ; Tue, 8 Sep 2020 13:35:33 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 659A920678 for ; Tue, 8 Sep 2020 13:35:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 659A920678 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-112-MUK5j-UgO9akp7y6ooiWRw-1; Tue, 08 Sep 2020 09:35:30 -0400 X-MC-Unique: MUK5j-UgO9akp7y6ooiWRw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D68171074657; Tue, 8 Sep 2020 13:35:26 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 805FE60C0F; Tue, 8 Sep 2020 13:35:26 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id C907B7A002; Tue, 8 Sep 2020 13:35:25 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 088DZMiD022384 for ; Tue, 8 Sep 2020 09:35:22 -0400 Received: by smtp.corp.redhat.com (Postfix) id 259E5110E9A0; Tue, 8 Sep 2020 13:35:22 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast03.extmail.prod.ext.rdu2.redhat.com [10.11.55.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1A730110E9A3 for ; Tue, 8 Sep 2020 13:35:19 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DC69D811E82 for ; Tue, 8 Sep 2020 13:35:19 +0000 (UTC) Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-39-XiINYxIpPYWrwAc5NNq2Bw-1; Tue, 08 Sep 2020 09:35:17 -0400 X-MC-Unique: XiINYxIpPYWrwAc5NNq2Bw-1 Received: by mail-ot1-f68.google.com with SMTP id c10so14821001otm.13 for ; Tue, 08 Sep 2020 06:35:17 -0700 (PDT) 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=gar4BreDCQ/72P6bchhSRHNsc6Zc5dSSb5ZIWUFYbnU=; b=OpcH2Sj8DZEuSYVFluYnV55AoQy4sHNU9L+qSaX+oUXhAXzu2c7i2NBmUnGTMTOEe4 sG4g4pw4+v+83iCoMjv+Pq/ftLrLlV6Q6LLUpop0GnZroqFbvVg2U76FhpsFJ5e4MouP kmRjo+Adzuz52HTawBl5cJ1zFbxp4XD7x4PjQSkP7E3Y4DQA3895SImD43Gl/k8+wDPy tDHYk1Vufuuz9M0KFEukY9vJRrFZ0jFzXMR2mZNW4cnfeFYkYtgdKPScVJzQBNXLH7VR qUUeJBqFLWHJ+ZfGMAPMKEkkJ4ksbZj5NMIB3DMNs3o1goKGTCcfme9/mlgBfzP8LPBz jTqQ== X-Gm-Message-State: AOAM531Sx6Q/6mPf3nTKJg1th2cZ0MFJ8E9hbb703Xd4Lb6BRzs+lyi6 dBwHWZUXXyqjmukEKm+r95vhsDaiPSU97XJoVWU= X-Google-Smtp-Source: ABdhPJyWhiQ0vShLlXuCv5fr448BVDeWmqjkRs6wxP3IGO8/JwS7/Gyogf/s6MDSZT/XRrzVYfRpZoeMQH4wTkN0STE= X-Received: by 2002:a9d:185:: with SMTP id e5mr18471022ote.135.1599572116933; Tue, 08 Sep 2020 06:35:16 -0700 (PDT) MIME-Version: 1.0 References: <20200826145247.10029-1-casey@schaufler-ca.com> <20200826145247.10029-6-casey@schaufler-ca.com> <1eeef766-405f-3800-c0cf-3eb008f9673e@schaufler-ca.com> <585600d7-70fb-0982-1e6b-ffd7b7c33e32@schaufler-ca.com> <9a58d14c-eaff-3acf-4689-925cf08ba406@canonical.com> In-Reply-To: From: Stephen Smalley Date: Tue, 8 Sep 2020 09:35:05 -0400 Message-ID: Subject: Re: [PATCH v20 05/23] net: Prepare UDS for security module stacking To: John Johansen X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false; X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-loop: linux-audit@redhat.com Cc: SElinux list , James Morris , Casey Schaufler , LSM List , linux-audit@redhat.com, Stephen Smalley X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Sep 7, 2020 at 9:28 PM Stephen Smalley wrote: > > On Sat, Sep 5, 2020 at 3:07 PM John Johansen > wrote: > > > > On 9/5/20 11:13 AM, Casey Schaufler wrote: > > > On 9/5/2020 6:25 AM, Paul Moore wrote: > > >> On Fri, Sep 4, 2020 at 7:58 PM Casey Schaufler wrote: > > >>> On 9/4/2020 2:53 PM, Paul Moore wrote: > > >>>> On Fri, Sep 4, 2020 at 5:35 PM Casey Schaufler wrote: > > >>>>> On 9/4/2020 1:08 PM, Paul Moore wrote: > > >> ... > > >> > > >>>> I understand the concerns you mention, they are all valid as far as > > >>>> I'm concerned, but I think we are going to get burned by this code as > > >>>> it currently stands. > > >>> Yes, I can see that. We're getting burned by the non-extensibility > > >>> of secids. It will take someone smarter than me to figure out how to > > >>> fit N secids into 32bits without danger of either failure or memory > > >>> allocation. > > >> Sooo what are the next steps here? It sounds like there is some > > >> agreement that the currently proposed unix_skb_params approach is a > > >> problem, but it also sounds like you just want to merge it anyway? > > > > > > There are real problems with all the approaches. This is by far the > > > least invasive of the lot. If this is acceptable for now I will commit > > > to including the dynamic allocation version in the full stacking > > > (e.g. Smack + SELinux) stage. If it isn't, well, this stage is going > > > to take even longer than it already has. Sigh. > > > > > > > > >> I was sorta hoping for something a bit better. > > > > > > I will be looking at alternatives. I am very much open to suggestions. > > > I'm not even 100% convinced that Stephen's objections to my separate > > > allocation strategy outweigh its advantages. If you have an opinion on > > > that, I'd love to hear it. > > > > > > > fwiw I prefer the separate allocation strategy, but as you have already > > said it trading off one set of problems for another. I would rather see > > this move forward and one set of trade offs isn't significantly worse > > than the other to me so, either wfm. > > I remain unclear that AppArmor needs this patch at all even when > support for SO_PEERSEC lands. > Contrary to the patch description, it is about supporting SCM_SECURITY > for datagram not SO_PEERSEC. And I don't know of any actual users of > SCM_SECURITY even for SELinux, just SO_PEERSEC. I remembered that systemd once tried using SCM_SECURITY but that was a bug since systemd was using it with stream sockets and that wasn't supported by the kernel at the time, https://bugzilla.redhat.com/show_bug.cgi?id=1224211, so systemd switched over to using SO_PEERSEC. Subsequently I did fix SCM_SECURITY to work with stream sockets via kernel commit 37a9a8df8ce9de6ea73349c9ac8bdf6ba4ec4f70 but SO_PEERSEC is still preferred. Looking around, I see that there is still one usage of SCM_SECURITY in systemd-journald but it doesn't seem to be required (if provided, journald will pass the label along but nothing seems to depend on it AFAICT). In any event, I don't believe this patch is needed to support stacking AppArmor. -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit