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=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 4AC50C433B4 for ; Fri, 23 Apr 2021 13:41:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CF53461450 for ; Fri, 23 Apr 2021 13:41:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF53461450 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 44B236B00A8; Fri, 23 Apr 2021 09:41:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 421CD8E0003; Fri, 23 Apr 2021 09:41:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 29CB46B00C1; Fri, 23 Apr 2021 09:41:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 0C84A6B00A8 for ; Fri, 23 Apr 2021 09:41:44 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BDD3618163987 for ; Fri, 23 Apr 2021 13:41:43 +0000 (UTC) X-FDA: 78063744486.39.A4C7174 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf09.hostedemail.com (Postfix) with ESMTP id EA8C26000135 for ; Fri, 23 Apr 2021 13:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619185302; 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=Ze4ahKnbOCWiAxmHjTl9e5R83LN6smcdaohyYDqcddU=; b=YCFvB/yw/3OmUDn6/dktUU5a2oLOh1Nqo3rHSzPdgCwb2U1IfzDAFmhwFwKGAm0A0jnsez FiyXgQJ6pc/GIZyhSd4g/4owI+lQjhwCpqmTcsKrzDNTw5jKMjTy+AdSvcyWLXDbGfto6c LiM+hSLeyiiADZ15BXG0IK1qzrpuioA= Received: from mail-yb1-f198.google.com (mail-yb1-f198.google.com [209.85.219.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-65-dlmRFUBQPPW-E4Y_ByLAPQ-1; Fri, 23 Apr 2021 09:41:41 -0400 X-MC-Unique: dlmRFUBQPPW-E4Y_ByLAPQ-1 Received: by mail-yb1-f198.google.com with SMTP id e8-20020a2587480000b02904e5857564e2so24263943ybn.16 for ; Fri, 23 Apr 2021 06:41:41 -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=Ze4ahKnbOCWiAxmHjTl9e5R83LN6smcdaohyYDqcddU=; b=uR2bkDU1eYHeVqrc5zJfNHntrE3WT231sncqH17DKWqSwY/kjJqP5LKPFYXFpTk94S Oj7elIgAYXjhhDHe2ENLxInpavpiBbUKziGXpZtgHH9jUPJ2C5ogHn4g3J4zBRB6uPa+ h4JyTsZWHQdGo+a/vMX6AOKNhNTV2ef9SnRyjMP2Rh3EiF15wWqQYdtF7qWL8tXq8nFH UvJhQ9BH/Xud/3MiWtnM1Wg+AfKt/W/v35qBGevnNhIAnOLHbsHe4hZ8QOgEHZNbfmXq 8nP16xj7uvBl4vSBR7Y1jJeh1BICORQWOjDnik1eg6A4KzhwTPZkADX2tGfoMSyBNO7W QIQw== X-Gm-Message-State: AOAM532WF3KT32MC1gkLeLS95SDrT+Xsf+cKcF6/EOR6WXR3GQKPDtKV 7JvHOqulJVARjtrDhtTnNuw1C2KDTho2tjvuIjC28E8lSS8xQ0JgvdR862tPqAzK+i9C+MUGuss VgXXxURCe3GJi0ZVdEkw5GZ9eLFE= X-Received: by 2002:a25:9085:: with SMTP id t5mr4967877ybl.26.1619185298027; Fri, 23 Apr 2021 06:41:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXNaViuyykB129+lJhNJo0S+WHcmw5kglqQvAOEW3Lkacoqm9Vvdzv9iHggDm7UBpnmciENcf5DP8f3KFEXko= X-Received: by 2002:a25:9085:: with SMTP id t5mr4967852ybl.26.1619185297789; Fri, 23 Apr 2021 06:41:37 -0700 (PDT) MIME-Version: 1.0 References: <20210421171446.785507-1-omosnace@redhat.com> <20210421171446.785507-3-omosnace@redhat.com> In-Reply-To: From: Ondrej Mosnacek Date: Fri, 23 Apr 2021 15:41:25 +0200 Message-ID: Subject: Re: [RFC PATCH 2/2] selinux: add capability to map anon inode types to separate classes To: Stephen Smalley Cc: SElinux list , Paul Moore , LSM List , "open list:MEMORY MANAGEMENT" , Linux FS Devel , linux-kernel , Lokesh Gidra 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-Rspamd-Queue-Id: EA8C26000135 X-Stat-Signature: r93xhc4ezak4a9ou45dk7toyhoy3qdmb X-Rspamd-Server: rspam02 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf09; 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: 1619185297-160711 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 Thu, Apr 22, 2021 at 3:21 PM Stephen Smalley wrote: > On Wed, Apr 21, 2021 at 1:14 PM Ondrej Mosnacek wrote: > > > > Unfortunately, the approach chosen in commit 29cd6591ab6f ("selinux: > > teach SELinux about anonymous inodes") to use a single class for all > > anon inodes and let the policy distinguish between them using named > > transitions turned out to have a rather unfortunate drawback. > > > > For example, suppose we have two types of anon inodes, "A" and "B", and > > we want to allow a set of domains (represented by an attribute "attr_x") > > certain set of permissions on anon inodes of type "A" that were created > > by the same domain, but at the same time disallow this set to access > > anon inodes of type "B" entirely. Since all inodes share the same class > > and we want to distinguish both the inode types and the domains that > > created them, we have no choice than to create separate types for the > > cartesian product of (domains that belong to attr_x) x ("A", "B") and > > add all the necessary allow and transition rules for each domain > > individually. > > > > This makes it very impractical to write sane policies for anon inodes in > > the future, as more anon inode types are added. Therefore, this patch > > implements an alternative approach that assigns a separate class to each > > type of anon inode. This allows the example above to be implemented > > without any transition rules and with just a single allow rule: > > > > allow attr_x self:A { ... }; > > > > In order to not break possible existing users of the already merged > > original approach, this patch also adds a new policy capability > > "extended_anon_inode_class" that needs to be set by the policy to enable > > the new behavior. > > > > I decided to keep the named transition mechanism in the new variant, > > since there might eventually be some extra information in the anon inode > > name that could be used in transitions. > > > > One minor annoyance is that the kernel still expects the policy to > > provide both classes (anon_inode and userfaultfd) regardless of the > > capability setting and if one of them is not defined in the policy, the > > kernel will print a warning when loading the policy. However, it doesn't > > seem worth to work around that in the kernel, as the policy can provide > > just the definition of the unused class(es) (and permissions) to avoid > > this warning. Keeping the legacy anon_inode class with some fallback > > rules may also be desirable to keep the policy compatible with kernels > > that only support anon_inode. > > > > Signed-off-by: Ondrej Mosnacek > > NAK. We do not want to introduce a new security class for every user > of anon inodes - that isn't what security classes are for. > For things like kvm device inodes, those should ultimately use the > inherited context from the related inode (the /dev/kvm inode itself). > That was the original intent of supporting the related inode. Hmm, so are you implying that anon inodes should be thought of the same as control /dev nodes? I.e. that even though there may be many one-time actual inodes created by different processes, they should be thought of as a single "static interface" to the respective kernel functionality? That would justify having a common type/label for all of them, but I'm not sure if it doesn't open some gap due to the possibility to pass the associated file descriptors between processes (as AFAIK, these can hold some context)... I thought this was supposed to resemble more the way BPF, perf_event, etc. support was implemented - the BPF and perf_event fds are also anon inodes under the hood, BTW - where each file descriptor is considered a separate object that inherits the label of its creator and there is some class separation (e.g. bpf vs. perf_event). -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.