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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA5FFC25B0E for ; Tue, 16 Aug 2022 22:12:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 128CD8D0002; Tue, 16 Aug 2022 18:12:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D9028D0001; Tue, 16 Aug 2022 18:12:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE2818D0002; Tue, 16 Aug 2022 18:12:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DEC258D0001 for ; Tue, 16 Aug 2022 18:12:13 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B51F240937 for ; Tue, 16 Aug 2022 22:12:13 +0000 (UTC) X-FDA: 79806854946.29.936D62D Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com [209.85.160.49]) by imf23.hostedemail.com (Postfix) with ESMTP id 4C6EC1401AE for ; Tue, 16 Aug 2022 22:12:13 +0000 (UTC) Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-10ea9ef5838so13242157fac.3 for ; Tue, 16 Aug 2022 15:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=bknMuEzY2g2ODMFx0pPstR6QEhnsKog5Pl0iH/Ldgz4=; b=sL5dB1VPJNsbf7G8+raTZ4CNHBvpk7wuUoHen4F/fRTlul2K/o6MnEL0QELNEgsXV5 8uwAQx9hINB2uTWQ0G+WTB+PukHYNee/MzAqYyyV44+Yri8pGj61r+lHfamUK8p8w4X7 QRKqDPOPL9df5lxT34qEXLNreDeG9SXoOiwcQAPOeFr88+qXNgL64ohaZHIVEk+mgB5R wnGXnCFP58BNzbyVX8OjR1IGJbgoEjD+wT7pAjEFqxbJu1di5xE14EIVzTnYMG1XM9Y9 6uf1djrUsKmdWrPsGSGSoKlADOPuJiThHSoMfwFLvak3qmxWc7ku1U1IrL0Q701vNeVo jU+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=bknMuEzY2g2ODMFx0pPstR6QEhnsKog5Pl0iH/Ldgz4=; b=5CxwZl3mD0OBJ5tacnF8rauZywMQa/OqcKp/InvMG+wWpqfGRELEYWjKnLuUx0S2un 3OWlAgnVISzgWv882amiMqAs9I5mDjVOVNm+UlXFdW2RENtJ/fQWpkLklb9HWmysgAYG k1Q3oJZTf11ihGbT3oI7ee28unfYwdubZfiSROHOhHzjvH3fvdPVPudcMoWJBiRWrfnT 2OnBu0he3UkgK/uF3UxVm1W/AYtYX+/VApMVMQCQQIB373zBNvV4ISyKmeQ7vm76Y51r 4oXcOWKdYS4dxyMne8zsZWIPcrS+ehbTY7tbH1SKiEZzzbDJLqwY+NvI9YYCtoV2+zA3 YPhg== X-Gm-Message-State: ACgBeo2GIh9YdO4g6kQlv7qsk4Bz33uji/EYoQRnvwgaeWQGX9WB4rKw Q7Q63Lu8/lNJrhOtoHn37uVRCSEh3cwAcQ73E9aF X-Google-Smtp-Source: AA6agR4Kj8XNYB9B3lGnewDxsdQnXfT+Fb5iBt539vCMF1wUyb8ZJN1qBsC0HMD5LPLcd7Vjw7gmG8QhiI7dUCI9BGQ= X-Received: by 2002:a05:6870:a78d:b0:11c:437b:ec70 with SMTP id x13-20020a056870a78d00b0011c437bec70mr320272oao.136.1660687932528; Tue, 16 Aug 2022 15:12:12 -0700 (PDT) MIME-Version: 1.0 References: <20220708093451.472870-1-omosnace@redhat.com> In-Reply-To: <20220708093451.472870-1-omosnace@redhat.com> From: Paul Moore Date: Tue, 16 Aug 2022 18:12:01 -0400 Message-ID: Subject: Re: [RFC PATCH RESEND] userfaultfd: open userfaultfds with O_RDONLY To: Ondrej Mosnacek Cc: Alexander Viro , Andrew Morton , Andrea Arcangeli , Peter Xu , David Hildenbrand , Lokesh Gidra , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-kernel@vger.kernel.org, "Robert O'Callahan" Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=sL5dB1VP; spf=none (imf23.hostedemail.com: domain of paul@paul-moore.com has no SPF policy when checking 209.85.160.49) smtp.mailfrom=paul@paul-moore.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660687933; a=rsa-sha256; cv=none; b=EARj+MUq6n4JEYnpNxXrRC3XfcpYZzvEHTobW3VCYGuG6cAG4qriggHvCvf+uAe4r5Yv/G w+O9g422B9N5EBOe4xREwvEWfFTa7gpfipipZcHrUFmDSM1QOBUEBT+2ssshTnBdEijWsw V7zE7CMDU8GU4bgwuFvLSjQeXYx2g6Y= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660687933; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bknMuEzY2g2ODMFx0pPstR6QEhnsKog5Pl0iH/Ldgz4=; b=zd7w+/2VD7E6p1/TPoNVC0bLDlihTPLX7PU36AZIWLoL5xINq0dkd7TrUn8BkYOJNJbdnR /hHPlF9aBsHISp/GlRokRJ37DlmNmjM+dQK6DCLV1AJt55xjxW2svHQbsHVp+Y2hBRV0cW kyXyA6MxYA+QovolEBbCdbMvjuTv3QI= Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=sL5dB1VP; spf=none (imf23.hostedemail.com: domain of paul@paul-moore.com has no SPF policy when checking 209.85.160.49) smtp.mailfrom=paul@paul-moore.com; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: fi4x7zeucacr7ho77e8hiye3za37uihf X-Rspamd-Queue-Id: 4C6EC1401AE X-HE-Tag: 1660687933-88288 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 Fri, Jul 8, 2022 at 5:35 AM Ondrej Mosnacek wrote: > > Since userfaultfd doesn't implement a write operation, it is more > appropriate to open it read-only. > > When userfaultfds are opened read-write like it is now, and such fd is > passed from one process to another, SELinux will check both read and > write permissions for the target process, even though it can't actually > do any write operation on the fd later. > > Inspired by the following bug report, which has hit the SELinux scenario > described above: > https://bugzilla.redhat.com/show_bug.cgi?id=1974559 > > Reported-by: Robert O'Callahan > Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization") > Signed-off-by: Ondrej Mosnacek > --- > > Resending as the last submission was ignored for over a year... > > https://lore.kernel.org/lkml/20210624152515.1844133-1-omosnace@redhat.com/T/ > > I marked this as RFC, because I'm not sure if this has any unwanted side > effects. I only ran this patch through selinux-testsuite, which has a > simple userfaultfd subtest, and a reproducer from the Bugzilla report. > > Please tell me whether this makes sense and/or if it passes any > userfaultfd tests you guys might have. > > fs/userfaultfd.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) VFS folks, any objection to this patch? It seems reasonable to me and I'd really prefer this to go in via the vfs tree, but I'm not above merging this via the lsm/next tree to get someone in vfs land to pay attention to this ... > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > index e943370107d0..8ccf00be63e1 100644 > --- a/fs/userfaultfd.c > +++ b/fs/userfaultfd.c > @@ -989,7 +989,7 @@ static int resolve_userfault_fork(struct userfaultfd_ctx *new, > int fd; > > fd = anon_inode_getfd_secure("[userfaultfd]", &userfaultfd_fops, new, > - O_RDWR | (new->flags & UFFD_SHARED_FCNTL_FLAGS), inode); > + O_RDONLY | (new->flags & UFFD_SHARED_FCNTL_FLAGS), inode); > if (fd < 0) > return fd; > > @@ -2090,7 +2090,7 @@ SYSCALL_DEFINE1(userfaultfd, int, flags) > mmgrab(ctx->mm); > > fd = anon_inode_getfd_secure("[userfaultfd]", &userfaultfd_fops, ctx, > - O_RDWR | (flags & UFFD_SHARED_FCNTL_FLAGS), NULL); > + O_RDONLY | (flags & UFFD_SHARED_FCNTL_FLAGS), NULL); > if (fd < 0) { > mmdrop(ctx->mm); > kmem_cache_free(userfaultfd_ctx_cachep, ctx); > -- > 2.36.1 -- paul-moore.com