Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp47326pxy; Wed, 21 Apr 2021 18:05:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4CHu05FW6GJdEbRioSYxE7mtjecoUFD4ywkqtcAwSNSWRAIJZhe/e4FlPtpHY3ZjSi3vj X-Received: by 2002:a63:c14c:: with SMTP id p12mr872101pgi.417.1619053524791; Wed, 21 Apr 2021 18:05:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619053524; cv=none; d=google.com; s=arc-20160816; b=rClHwsTMBMYBikpFsomVYcsbc33jHcqvzVi7RWcvVCGS+HupN7TtHDirAt+KDTASaC s9Fm/DItnBfJjlJWJuFDjDU3EuvV3tqj1Gjam5Zjtm361VMX4AnK8DATEVSPvnWeKZdq b7YTYd//LMR8Gcl5hvfT/D4DxrN9jUORM/VD52xPm58IZDxdmahoGmQmhuU35tekSKHb EOkC9ACgP+H2aTq/KmMJKfXADLw4k+K2UnYBOjccosWBOjUgoESpupaeArR2j4T3NCsK l5Ox6MBI1u7ffJz9HDSMD+iRqcz1GjGDkmMfKzT06SKoNbLdqoueOFi/0E5nu/OrQuJ8 S0bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=7Ds+L1bCP6+6WbzB+/50dXw+9s8exJ7s0FvADavIhEQ=; b=oAqbE6elNsSOwVtcw4qBQy0xxhwAW2NWmCPCSJTvyp0bcCINSQIxEv5uRBeOMAG2Ao pMXE4/jNSgW5+ZYgaWmgxKMXhDbDnQftwdMfL+n/O8wvxxM7Kf9/thLvy1lgXpwCnvz+ SG+AcVWpeQ4/QbX9buPyYkVuwIgqHQKxn5wFo6j0ihpaQJWeL4RMQSQqRIaDu93HtWHS HJZWSkX+4IDDzHULUvRSho5sQTcTqogMnlYy34TCWEtFvGPwDwGpE9ACDOVKaP3XayvQ 6WS95vEJGR+aGU+ThbuDWHheJw00be3jpvHnmYfFktFCEE+FQaE++dkIqEVt5NZdNf02 RJrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PvlAzhw0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z12si1324398pln.80.2021.04.21.18.05.13; Wed, 21 Apr 2021 18:05:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PvlAzhw0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244673AbhDURPn (ORCPT + 99 others); Wed, 21 Apr 2021 13:15:43 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:22109 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241487AbhDURPb (ORCPT ); Wed, 21 Apr 2021 13:15:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619025297; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=7Ds+L1bCP6+6WbzB+/50dXw+9s8exJ7s0FvADavIhEQ=; b=PvlAzhw0jdpOXutQmo5/QE1wEP1cw0GFd1fWU7MgSq4rPzbHkzTzyQkvey6X513C4DV35F a+Qm82UoEsynmvZvfyi6pWKQHuO2JbX9q/K7JKh/Kc8oMCADwfjbOLwYnYbH7dMLrCRKzE W9f5pjnwVUjOKy72u4ebCOEWs0fQf0w= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-583-3rfhUMYVPKGbSisJWlF22Q-1; Wed, 21 Apr 2021 13:14:50 -0400 X-MC-Unique: 3rfhUMYVPKGbSisJWlF22Q-1 Received: by mail-ej1-f72.google.com with SMTP id o25-20020a1709061d59b029037c94676df5so6163108ejh.7 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=hcPaqDjR5B91MJZMCd9AVyx/6SuK1FVPljnkbzq+kPcjrZ+98HAw24sZGsVYWPvqrC ZEx3LglO2uvlowoWS6//ympmq8be4U7Le2c6k9kJ1e5T/bj3lr6PuJjH4k8bjPxOORZC kXv7wep2GJJUEjmK21k4Ltny36/kPqu6DC3Q8Qxidjc2llgSS9VHkdPoy9huyMXGWfOo 7ej3ZBZjHCZgc0Gf8pruBge6IXMw1k1EbP5Tc27eucIAhFecJEyUKESonDiEZEIjAhiS YGvyPFq0dnL8lixBr2HP9FYQYzMr+gq43n22uxWLqWxR+Ozyq7/n3Mm66NbeIh9DeT/U LqYg== X-Gm-Message-State: AOAM530neIjZTQ2htjulqx8/LTxoExF/vk8BBqr+GiziWZUH4xhGY99U 1Opax8JTm729QHyvLKptGolLRK54cPyCoR0wqxo+8Vw50YjAUm0nMvwQNLfQRhu/LadiFz5Y2Ke 1H3LD6eo60dAWovxCBYD2n3/s X-Received: by 2002:a05:6402:290:: with SMTP id l16mr29082595edv.337.1619025289506; Wed, 21 Apr 2021 10:14:49 -0700 (PDT) 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 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(-) -- 2.30.2