Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3475369pxu; Sun, 11 Oct 2020 11:01:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzxW4NxguSHpOulXpBIbKqWo64KSaDauAMOCppDdx45DK823pNkuFIuqxWerSISteCqKiya X-Received: by 2002:a50:e40b:: with SMTP id d11mr10236837edm.198.1602439305431; Sun, 11 Oct 2020 11:01:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602439305; cv=none; d=google.com; s=arc-20160816; b=EPtviicc4+Vm7MQ2C1SSEfriwysUQfzpykgFtDpzlOGS9zlu3rMdg2RUQZ4QAjt9qK XVpGQlngYTx5639qS+zXp19JYyp5ZwYwSw7nyKOZOtMV4P5Z5KnIGjDuajDP0tSs6IKw jaXhpDp2W131AVkqybugXKk/wahrzA2DoNEQuxJ1SOVvrjNEluRMj2Xc7gwh2pwVeRvi sNlEjKEZbqOHtGk5NO2S1ao7DVG0ChmfqzmQXLhqYV/3wyM2O6IuSE43eI/DwyUxO/AX yKC8QJfDHElE2fvSaa00MhKtx0NoxdeMPRfPqskmHlxbmUzI/8qHvweT2QICUjYeqFfi 8fsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id:date :sender:dkim-signature; bh=0y7LeAQ9NHAeCjBB9f+BCZL8bpbABLEfm+/TZuUzjwI=; b=JKSVOTZIIo1TMZXIz7JG64VqTZKEzW2WJ8p23n82fBPC+A6WeBdgUB8f9u6Jv7YqNW JxtXyO5kGaBZiL5y3h00IQudmziBYJ+ZucKZJyPnA7OWi61PVmEvey3Rn8wSd4a+AuWX nGaRgNT3EQytG9XXJy9AUMerQIeAWYA5mtJhbkYOMvUDdMIwRI5prco3tc5TNGxeLF6W mhhaIIx4RhHVDJbeGYuSbJhTGPzNJQmlWCXh3+bJ9NqusRbXBFJVE+h/biIDS4Y4w84K W/O9AVCek7/0IYFlG9R3RqyL/gPtpq0wFgN+vzUvNamJ35xvjEMI19vq+/KW3YEXPOlp 5QoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="P/8oZtrK"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mb16si6575845ejb.701.2020.10.11.11.01.22; Sun, 11 Oct 2020 11:01:45 -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=@google.com header.s=20161025 header.b="P/8oZtrK"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729207AbgJKI3n (ORCPT + 99 others); Sun, 11 Oct 2020 04:29:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729192AbgJKI3m (ORCPT ); Sun, 11 Oct 2020 04:29:42 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA02CC0613D0 for ; Sun, 11 Oct 2020 01:29:40 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id m62so10424571ybb.6 for ; Sun, 11 Oct 2020 01:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:message-id:mime-version:subject:from:to:cc; bh=0y7LeAQ9NHAeCjBB9f+BCZL8bpbABLEfm+/TZuUzjwI=; b=P/8oZtrKfZFy8Ts2UxpZQAjixDV02pYNluizK8Xze/QVGnZ7Fw0f0AsF2wyJsYEZKO jr4XQvuOaAStlzQOSTBDH4dpQ+NIYOCurxPIwoJjDhdnoUApWY9IHK1mUssePS90a/tU cFVP4/9Bf/0HZCHjDkVPkEzkJtP0MWq0iP6rw4aAR+I0ZPn6h5F4Q+yD9PH7prBMS6Ew 45YMMQZQD+QLfOBJpylWxvfBF/Nw6hvsxuFwjZGFaGXDc6a33Kt8enlIo1TJ+dNEbZCP l9DskxWobk1uKD3WliBxqUqbfpK1kfMXAHQ+11Ag4n4CK0CpFYdXcxW3j+bp0FP+bcxc nR5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:message-id:mime-version:subject:from :to:cc; bh=0y7LeAQ9NHAeCjBB9f+BCZL8bpbABLEfm+/TZuUzjwI=; b=ExV1+tZ60oHtZWZJEsYtsHxrF+B39o6jH+AZPK7JAZ5Guap4wyFN1/w4swMWnB0If9 UaPRWOcCJLN4h6SuLtuMb0Zb9pWlVmGOynD5DaRxlU68rxUDOF/sJJQbt/skDe0dR2yW bMqk3cU8s9G0G6WzBe57r6XQzKr8hq9kM5Xm67/HGUJlQtijVtIDcilfTyG8YSiErwAI mq+LJMKBp95ljbBdmNNHRWJ3ymcD+hRGEau3JDEyIjsrvd8UyDYzGBRovhrRjmpKZJGD xKw7CvCmgP/VcGweVE75Yop6xBwOy+pv2PdNGunaekgcSgpnABw5IT4G1ahw5LlSySRR DQIQ== X-Gm-Message-State: AOAM531UYAHa8PI0Ojukx5IuthLixX/Q1GX9gn6QMnCPYRXoLqKgxiFk us7T6HssLP5po47bY6XFS2r5xcQ9Pu+NRSBXiA== Sender: "lokeshgidra via sendgmr" X-Received: from lg.mtv.corp.google.com ([2620:15c:211:202:f693:9fff:fef4:29dd]) (user=lokeshgidra job=sendgmr) by 2002:a25:d9c8:: with SMTP id q191mr19972156ybg.475.1602404979671; Sun, 11 Oct 2020 01:29:39 -0700 (PDT) Date: Sun, 11 Oct 2020 01:29:33 -0700 Message-Id: <20201011082936.4131726-1-lokeshgidra@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.28.0.1011.ga647a8990f-goog Subject: [PATCH v10 0/3] SELinux support for anonymous inodes and UFFD From: Lokesh Gidra To: Alexander Viro , James Morris , Stephen Smalley , Casey Schaufler , Eric Biggers Cc: "Serge E. Hallyn" , Paul Moore , Eric Paris , Lokesh Gidra , Daniel Colascione , Kees Cook , "Eric W. Biederman" , KP Singh , David Howells , Thomas Cedeno , Anders Roxell , Sami Tolvanen , Matthew Garrett , Aaron Goidel , Randy Dunlap , "Joel Fernandes (Google)" , YueHaibing , Christian Brauner , Alexei Starovoitov , Alexey Budankov , Adrian Reber , Aleksa Sarai , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, kaleshsingh@google.com, calin@google.com, surenb@google.com, nnk@google.com, jeffv@google.com, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Userfaultfd in unprivileged contexts could be potentially very useful. We'd like to harden userfaultfd to make such unprivileged use less risky. This patch series allows SELinux to manage userfaultfd file descriptors and in the future, other kinds of anonymous-inode-based file descriptor. SELinux policy authors can apply policy types to anonymous inodes by providing name-based transition rules keyed off the anonymous inode internal name ( "[userfaultfd]" in the case of userfaultfd(2) file descriptors) and applying policy to the new SIDs thus produced. With SELinux managed userfaultfd, an admin can control creation and movement of the file descriptors. In particular, handling of a userfaultfd descriptor by a different process is essentially a ptrace access into the process, without any of the corresponding security_ptrace_access_check() checks. For privacy, the admin may want to deny such accesses, which is possible with SELinux support. Inside the kernel, a new anon_inode interface, anon_inode_getfd_secure, allows callers to opt into this SELinux management. In this new "secure" mode, anon_inodes create new ephemeral inodes for anonymous file objects instead of reusing the normal anon_inodes singleton dummy inode. A new LSM hook gives security modules an opportunity to configure and veto these ephemeral inodes. This patch series is one of two fork of [1] and is an alternative to [2]. The primary difference between the two patch series is that this partch series creates a unique inode for each "secure" anonymous inode, while the other patch series ([2]) continues using the singleton dummy anonymous inode and adds a way to attach SELinux security information directly to file objects. I prefer the approach in this patch series because 1) it's a smaller patch than [2], and 2) it produces a more regular security architecture: in this patch series, secure anonymous inodes aren't S_PRIVATE and they maintain the SELinux property that the label for a file is in its inode. We do need an additional inode per anonymous file, but per-struct-file inode creation doesn't seem to be a problem for pipes and sockets. The previous version of this feature ([1]) created a new SELinux security class for userfaultfd file descriptors. This version adopts the generic transition-based approach of [2]. This patch series also differs from [2] in that it doesn't affect all anonymous inodes right away --- instead requiring anon_inodes callers to opt in --- but this difference isn't one of basic approach. The important question to resolve is whether we should be creating new inodes or enhancing per-file data. Changes from the first version of the patch: - Removed some error checks - Defined a new anon_inode SELinux class to resolve the ambiguity in [3] - Inherit sclass as well as descriptor from context inode Changes from the second version of the patch: - Fixed example policy in the commit message to reflect the use of the new anon_inode class. Changes from the third version of the patch: - Dropped the fops parameter to the LSM hook - Documented hook parameters - Fixed incorrect class used for SELinux transition - Removed stray UFFD changed early in the series - Removed a redundant ERR_PTR(PTR_ERR()) Changes from the fourth version of the patch: - Removed an unused parameter from an internal function - Fixed function documentation Changes from the fifth version of the patch: - Fixed function documentation in fs/anon_inodes.c and include/linux/lsm_hooks.h - Used anon_inode_getfd_secure() in userfaultfd() syscall and removed owner from userfaultfd_ctx. Changes from the sixth version of the patch: - Removed definition of anon_inode_getfile_secure() as there are no callers. - Simplified function description of anon_inode_getfd_secure(). - Elaborated more on the purpose of 'context_inode' in commit message. Changes from the seventh version of the patch: - Fixed error handling in _anon_inode_getfile(). - Fixed minor comment and indentation related issues. Changes from the eighth version of the patch: - Replaced selinux_state.initialized with selinux_state.initialized Changes from the ninth version of the patch: - Fixed function names in fs/anon_inodes.c - Fixed comment of anon_inode_getfd_secure() - Fixed name of the patch wherein userfaultfd code uses anon_inode_getfd_secure() [1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/ [2] https://lore.kernel.org/linux-fsdevel/20200213194157.5877-1-sds@tycho.nsa.gov/ [3] https://lore.kernel.org/lkml/23f725ca-5b5a-5938-fcc8-5bbbfc9ba9bc@tycho.nsa.gov/ Daniel Colascione (3): Add a new LSM-supporting anonymous inode interface Teach SELinux about anonymous inodes Use secure anon inodes for userfaultfd fs/anon_inodes.c | 148 ++++++++++++++++++++-------- fs/userfaultfd.c | 19 ++-- include/linux/anon_inodes.h | 8 ++ include/linux/lsm_hook_defs.h | 2 + include/linux/lsm_hooks.h | 9 ++ include/linux/security.h | 10 ++ security/security.c | 8 ++ security/selinux/hooks.c | 53 ++++++++++ security/selinux/include/classmap.h | 2 + 9 files changed, 210 insertions(+), 49 deletions(-) -- 2.28.0.1011.ga647a8990f-goog