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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 CF79EC433ED for ; Thu, 22 Apr 2021 11:40:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1CD4761426 for ; Thu, 22 Apr 2021 11:40:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1CD4761426 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 536DD6B006C; Thu, 22 Apr 2021 07:40:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E6D76B006E; Thu, 22 Apr 2021 07:40:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 360076B0070; Thu, 22 Apr 2021 07:40:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0131.hostedemail.com [216.40.44.131]) by kanga.kvack.org (Postfix) with ESMTP id 100BB6B006C for ; Thu, 22 Apr 2021 07:40:03 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B837A8248047 for ; Thu, 22 Apr 2021 11:40:02 +0000 (UTC) X-FDA: 78059809044.04.7A181C7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 9CF352000268 for ; Thu, 22 Apr 2021 11:39:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619091601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uMXkQKD92XEqLOdKkZ9LkipLsjeMEu880iIF7KLHuos=; b=EeLIwUawfuiWRLamhWpuccdzl1+R5D+6ZBbMoBLfkrz/tOtOFUtEt/TSUXG42U/dUgHcd0 p1pjcqfQgXmHF+EhTmjDyz6Mm1mnc7sfvQ75+SHJP3NdS6syFjRyNMw7bLhDbfJEBPkNoe Li6xktHyToKT02rs4bcZVuqTmkqW/nU= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-203-2beZpvFRN6KdquOSqUtXeA-1; Thu, 22 Apr 2021 07:39:52 -0400 X-MC-Unique: 2beZpvFRN6KdquOSqUtXeA-1 Received: by mail-yb1-f200.google.com with SMTP id f7-20020a5b0c070000b02904e9a56ee7e7so19598292ybq.9 for ; Thu, 22 Apr 2021 04:39:51 -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=uMXkQKD92XEqLOdKkZ9LkipLsjeMEu880iIF7KLHuos=; b=RfRr1U3XH9uNGHa19+JzwXS+ULWIEk1+NKO6MlxhC8o6mbl9orjxIPrczWnaTuN5sU 5nF+i4PQ1u8CF0C+NGSB8RGJDT6D5g/Sj73n7iXph9+0uy3OeOCXXKceCctjgbF1GunG xctwF/ak07t5TNBaUhEqhzWtosK5IxJcr19gQetfMCJV/NtUaikV0yJoMOgJo/27q6Hl ntVw8O4VrvNhGAf2pStFvuENq2/N6MXMCHY7Kz5xUWssh8RIKcV0tcq56iQ53/j7SCl3 4FywoFn3ulKFYVmVyWI6mJ+U/8lt/6P/+kFS6bl0Mq2fDDId3Q0FfvZa057aroDcY0yB 4fqw== X-Gm-Message-State: AOAM532B86fFYHJqNcrzxpBPHrNaJajM9JaLcC3jxB+rG3T/if5rCndn pddrUhDcWI/OejyxWNmC8/4QGO16z4AWit6dpJYVP0fVn/P7L/tlIsVpL5/w7as47wtK2REJVZJ fQVS/8ClHz05xTOciL8k9O0z3hPM= X-Received: by 2002:a25:7085:: with SMTP id l127mr4068966ybc.293.1619091591518; Thu, 22 Apr 2021 04:39:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyhE6DS/eW1dR9xemDwBcQEmjxrQY+fv1G9l6m2UGwYtINpsqaUV9AJsTDjlsF+gV/DTMftEHXE3GlbORd3Hk= X-Received: by 2002:a25:7085:: with SMTP id l127mr4068951ybc.293.1619091591336; Thu, 22 Apr 2021 04:39:51 -0700 (PDT) MIME-Version: 1.0 References: <20210421171446.785507-1-omosnace@redhat.com> In-Reply-To: From: Ondrej Mosnacek Date: Thu, 22 Apr 2021 13:39:39 +0200 Message-ID: Subject: Re: [RFC PATCH 0/2] selinux,anon_inodes: Use a separate SELinux class for each type of anon inode To: Paul Moore Cc: SElinux list , Linux Security Module list , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Linux kernel mailing list , Lokesh Gidra , Stephen Smalley Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=omosnace@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: jxwregrenebk1yidfuuzgsnmkpmktbm5 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9CF352000268 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf11; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619091588-666681 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Apr 21, 2021 at 10:38 PM Paul Moore wrote: > On Wed, Apr 21, 2021 at 1:14 PM Ondrej Mosnacek wrote: > > > > This series aims to correct a design flaw in the original anon_inode > > SELinux support that would make it hard to write policies for anonymous > > inodes once more types of them are supported (currently only userfaultfd > > inodes are). A more detailed rationale is provided in the second patch. > > > > The first patch extends the anon_inode_getfd_secure() function to accept > > an additional numeric identifier that represents the type of the > > anonymous inode being created, which is passed to the LSMs via > > security_inode_init_security_anon(). > > > > The second patch then introduces a new SELinux policy capability that > > allow policies to opt-in to have a separate class used for each type of > > anon inode. That means that the "old way" will still > > ... will what? :) Whoops, I thought I had gone over all the text enough times, but apparently not :) It should have said something along the lines of: ...will still work and will be used by default. > > I think it would be a very good idea if you could provide some > concrete examples of actual policy problems encountered using the > current approach. I haven't looked at these patches very seriously > yet, but my initial reaction is not "oh yes, we definitely need this". An example is provided in patch 2. It is a generalized problem that we would eventually run into in Fedora policy (at least) with the unconfined_domain_type attribute and so far only hypothetical future types of anon inodes. -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.