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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 DC832C5DF62 for ; Tue, 5 Nov 2019 17:30:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A5821214D8 for ; Tue, 5 Nov 2019 17:30:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RzvGG4JR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5821214D8 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 336126B0003; Tue, 5 Nov 2019 12:30:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E7AE6B0005; Tue, 5 Nov 2019 12:30:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FCDE6B0006; Tue, 5 Nov 2019 12:30:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id 08F726B0003 for ; Tue, 5 Nov 2019 12:30:31 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id A28384417 for ; Tue, 5 Nov 2019 17:30:30 +0000 (UTC) X-FDA: 76122913020.04.van66_46400300115d X-HE-Tag: van66_46400300115d X-Filterd-Recvd-Size: 5433 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 Nov 2019 17:30:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572975029; 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: in-reply-to:in-reply-to:references:references; bh=R4CAvK29IQ9BTMooH1oXZfErhOK7uWCBlP8KR7GiQus=; b=RzvGG4JRu8vgkLcsxwo8Ax3RWQ0bgvRYomH4cjX4HKOmmwyvj9VS+pvB+qXL0Hp9jac4Lw 7PHFylyeKzYt8j8ZEHk1YJ3E65mkR30Ikw+7QjvSSsgRRu+kBtnmAfb5sxmjfxkNOdnmSt 8U1gIUTq8IIuo9L9Lrc1gz6iX9kCofI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-354-jGWJEnvkP0WG-IUuzHi1ZA-1; Tue, 05 Nov 2019 12:30:26 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2C945107ACC3; Tue, 5 Nov 2019 17:30:24 +0000 (UTC) Received: from mail (ovpn-121-157.rdu2.redhat.com [10.10.121.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D666619C6A; Tue, 5 Nov 2019 17:30:23 +0000 (UTC) Date: Tue, 5 Nov 2019 12:30:23 -0500 From: Andrea Arcangeli To: Daniel Colascione Cc: Andy Lutomirski , Mike Rapoport , linux-kernel , Andrew Morton , Jann Horn , Linus Torvalds , Lokesh Gidra , Nick Kralevich , Nosh Minwalla , Pavel Emelyanov , Tim Murray , Linux API , linux-mm Subject: Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK Message-ID: <20191105173023.GN30717@redhat.com> References: <1572967777-8812-1-git-send-email-rppt@linux.ibm.com> <1572967777-8812-2-git-send-email-rppt@linux.ibm.com> <20191105163316.GI30717@redhat.com> <20191105165556.GK30717@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: jGWJEnvkP0WG-IUuzHi1ZA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 Tue, Nov 05, 2019 at 09:02:09AM -0800, Daniel Colascione wrote: > And you're suggesting making a security check work weirdly unlike most > other security checks because you hope it'll get removed one day? I didn't actually suggest that, I was only asking clarifications that I understood correctly because up until that point you didn't seem to say that the "permission check" needs to remain in UFFDIO_API. > Temporary solutions aren't, and if something goes into the kernel at > all, it's worth getting right. The general rule is that access checks > happen at open time. The kernel has already been bitten by UFFD > exempting itself from the normal rules (e.g., the > read(2)-makes-a-file-descriptor thing) in the name of expediency. > There shouldn't be any more exceptions. It didn't occur to me that not doing the measurement in the syscall that opens an fd is weird. The posted patch doesn't work any different than fscrypt_ioctl_add_key in FS_IOC_ADD_ENCRYPTION_KEY of ext4 and others, or btrfs_ioctl_fssetxattr or a ton of other examples where permissions are checked directly the in ioctl of the files and the measurement is also done in the ioctl and not in the open() as you suggest as the only non-weird solution that should exist in the kernel. I can surely provide a lot more examples of the exact same paradigm where the measurement of the capability is done in the ioctl, those are the first two examples that show up so it's unlikely they're the only ones. So overall I didn't think this was something wrong to do, or weird or something particularly new and I didn't look like we were bitting anything with it. And more than in the name of expediency this simply looks preferable to keep the complexity of the kernel low which in turns it means it's going to be more secure and simpler to maintain. Especially considering this code is likely to be modified later. Said that I've nothing contrary to do the more complex solution if that's the correct thing to do despite more complex and despite the code is pending for removal anyway, just I don't see any difference between the current simple patch to what ext4_ioctl does in FS_IOC_ADD_ENCRYPTION_KEY + FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR.