From patchwork Wed Apr 21 17:14:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ondrej Mosnacek X-Patchwork-Id: 12216637 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=-11.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 3B802C433ED for ; Wed, 21 Apr 2021 17:14:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B8397613CE for ; Wed, 21 Apr 2021 17:14:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8397613CE 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 270A66B0036; Wed, 21 Apr 2021 13:14:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FB316B006E; Wed, 21 Apr 2021 13:14:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04BD66B0070; Wed, 21 Apr 2021 13:14:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id D45466B0036 for ; Wed, 21 Apr 2021 13:14:53 -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 8214B8248068 for ; Wed, 21 Apr 2021 17:14:53 +0000 (UTC) X-FDA: 78057024066.04.3D76D5E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf19.hostedemail.com (Postfix) with ESMTP id C465D90009FB for ; Wed, 21 Apr 2021 17:14:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619025292; 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: content-transfer-encoding:content-transfer-encoding; bh=7Ds+L1bCP6+6WbzB+/50dXw+9s8exJ7s0FvADavIhEQ=; b=hQ0u4CNW1Ls/3k3HS+DAfkO8uDwf8u4IWGUNSZ/kkcWz2JqD0piss7D+I0LUqrP3/mq7zH CZWScdBNFu8Qpq6U6Z8GNHI3tLpTxnNkmGWDFZjEY7tChYDApwcFmuvrvnr49cwYQFcT/Z ahxAr/rd40lpiukoDASTOBELlQj1NCQ= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-229-iBazqGm1NY6Hyrlux84SBA-1; Wed, 21 Apr 2021 13:14:50 -0400 X-MC-Unique: iBazqGm1NY6Hyrlux84SBA-1 Received: by mail-ed1-f72.google.com with SMTP id bf25-20020a0564021a59b0290385169cebf8so8011518edb.8 for ; Wed, 21 Apr 2021 10:14:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=7Ds+L1bCP6+6WbzB+/50dXw+9s8exJ7s0FvADavIhEQ=; b=fAqfIdLbIXSGlZwbJ6gaFH3Ed04NmG5QljdztrreEYQ5/WFNWmMWSn31/f34CqHwsW bAsGoM2M12HlyCiR6aZhCeD9bmjcf0kc3RnBJ9pbkprMRcxkOgJfbs5qJOGthlW01N3K GiZXpbHP4WRA7izaiH1nXQ2+rsIB9quKiLcw+5bR0uoOCn2yAl1QWMwPOGhGcdj+CMjm DcrPZyW3yUg5p35Lc/42q2Of2I0X3IAWe6hdy4T9M2kIHnoHo55Kg/RYrnzkkWwF3zQ3 HZC7MPxX4tt6FKf+lVc7pZ0+//mhpJ/chz+Afu5NcJ9g8DmPECee+vxLRVDY6b/BaQ4H djlA== X-Gm-Message-State: AOAM531OGXq098NxLurWhdQUeq/f/05Dvs58PCYzdvtJYTROrrBmDPip Y525H0iftI9A7WQaZ8HcCKOEEp4qxdgz9flwwoBXCtB9H50BxDdthz61GCsA/GZ6umeSP7816or wcPD4Gzd21vY= X-Received: by 2002:a05:6402:290:: with SMTP id l16mr29082609edv.337.1619025289571; Wed, 21 Apr 2021 10:14:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmoKETRUuKqjG2OlKoFygbPK3HDWwNtdSKU+JS0tzwEYE4lpqCN0fHqQM+w+zccUEMLCoX8w== X-Received: by 2002:a05:6402:290:: with SMTP id l16mr29082582edv.337.1619025289299; Wed, 21 Apr 2021 10:14:49 -0700 (PDT) Received: from localhost.localdomain ([2a02:8308:b105:dd00:277b:6436:24db:9466]) by smtp.gmail.com with ESMTPSA id i1sm22905edt.33.2021.04.21.10.14.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Apr 2021 10:14:48 -0700 (PDT) From: Ondrej Mosnacek To: selinux@vger.kernel.org, Paul Moore Cc: linux-security-module@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Lokesh Gidra , Stephen Smalley Subject: [RFC PATCH 0/2] selinux,anon_inodes: Use a separate SELinux class for each type of anon inode Date: Wed, 21 Apr 2021 19:14:44 +0200 Message-Id: <20210421171446.785507-1-omosnace@redhat.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 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 X-Stat-Signature: e1zan6xj7xok64iqc6h3ojcfaob3a3eb X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C465D90009FB Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf19; 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: 1619025269-219524 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 I wish I had realized the practical consequences earlier, while the patches were still under review, but it only started to sink in after the authors themselves later raised the issue in an off-list conversation. Even then, I still hoped it wouldn't be that bad, but the more I thought about how to apply this in an actual policy, the more I realized how much pain it would be to work with the current design, so I decided to propose these changes. I hope this will be an acceptable solution. A selinux-testsuite patch that adapts the userfaultfd test to work also with the new policy capability enabled will follow. Ondrej Mosnacek (2): LSM,anon_inodes: explicitly distinguish anon inode types selinux: add capability to map anon inode types to separate classes fs/anon_inodes.c | 42 +++++++++++++--------- fs/userfaultfd.c | 6 ++-- include/linux/anon_inodes.h | 4 ++- include/linux/lsm_hook_defs.h | 3 +- include/linux/security.h | 19 ++++++++++ security/security.c | 3 +- security/selinux/hooks.c | 28 ++++++++++++++- security/selinux/include/classmap.h | 2 ++ security/selinux/include/policycap.h | 1 + security/selinux/include/policycap_names.h | 3 +- security/selinux/include/security.h | 7 ++++ 11 files changed, 95 insertions(+), 23 deletions(-)