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 4B9A8C5DF60 for ; Thu, 7 Nov 2019 19:28:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 126E32087E for ; Thu, 7 Nov 2019 19:28:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YqhmYVEW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 126E32087E 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 7D9376B0003; Thu, 7 Nov 2019 14:28:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7628D6B0005; Thu, 7 Nov 2019 14:28:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62AC16B0007; Thu, 7 Nov 2019 14:28:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0079.hostedemail.com [216.40.44.79]) by kanga.kvack.org (Postfix) with ESMTP id 48B266B0003 for ; Thu, 7 Nov 2019 14:28:04 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id DD0A1181AEF1F for ; Thu, 7 Nov 2019 19:28:03 +0000 (UTC) X-FDA: 76130466846.04.slope77_808ca8a45e030 X-HE-Tag: slope77_808ca8a45e030 X-Filterd-Recvd-Size: 5483 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 19:28:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573154882; 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=5GOtSEPvdxYm2pxjUsA4qBhfGS9ZCElHaPyIXVtMmQI=; b=YqhmYVEW2e/W1KswTW11LGB6KjIrOS3H2tg14Dx7dbIMFxfNWfcblKfNVKfqNWDo6bZoUc o8nTPPNLooGFv5cnVDltRR9tQS68QaJpWpEwO9k/yFZKMDRfOnndDjGMgYrZjJbfKURgbU MDhU17zI6EkaRL75+bQB3iJtZ2ijx9o= 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-294-F77lJWRLMVywhZ5pj1TsMQ-1; Thu, 07 Nov 2019 14:27:58 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 44B3F1005500; Thu, 7 Nov 2019 19:27:56 +0000 (UTC) Received: from mail (ovpn-121-157.rdu2.redhat.com [10.10.121.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0DF045E240; Thu, 7 Nov 2019 19:27:56 +0000 (UTC) Date: Thu, 7 Nov 2019 14:27:55 -0500 From: Andrea Arcangeli To: Daniel Colascione Cc: Mike Rapoport , Andy Lutomirski , 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: <20191107192755.GM17896@redhat.com> References: <20191105162424.GH30717@redhat.com> <20191107083902.GB3247@linux.ibm.com> <20191107153801.GF17896@redhat.com> <20191107182259.GK17896@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-MC-Unique: F77lJWRLMVywhZ5pj1TsMQ-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 Thu, Nov 07, 2019 at 10:50:26AM -0800, Daniel Colascione wrote: > On Thu, Nov 7, 2019 at 10:23 AM Andrea Arcangeli wr= ote: > > Not all software will do this after calling recvmsg: > > > > if (cmsg->cmsg_type =3D=3D SCM_RIGHTS) { > > /* oops we got attacked and an fd was involountarily installed > > because we received another AF_UNIX from a malicious attacker > > in control of the other end of the SCM_RIGHTS-receiving > > AF_UNIX connection instead of our expected socket family > > which doesn't even support SCM_RIGHTS so we would never have > > noticed an fd was installed after recvmsg */ > > } >=20 > If a program omits this code after calling recvmsg on a file > descriptor of unknown provenance and the program breaks, it's the > program's fault. [..] Hmm, ok, would it be possible to do a research effort and check how much software that receives an fd through SCM_RIGHTS and then calls recvmsg on it, always remembers to follow the recvsmg with a if (cmsg->cmsg_type =3D=3D SCM_RIGHTS) path that closes the involuntarily opened fd? Frankly until today, I didn't realize that not adding a specialized "cmsg->cmsg_type =3D=3D SCM_RIGHTS" check after every recvmsg executed on any fd received with SCM_RIGHTS, was a program's fault and it made the program vulnerable (non robust) from an attack from the other end of the AF_UNIX pipe just like if the program issued a read() with uffd event fork being sent through SCM_RIGHTS (except in that case it wasn't program's fault because read had not to install the fd while recvmsg can always install fd if cmsg_type =3D=3D SCM_RIGHTS is returned). The main argument in favor of recvmsg would be that even if we use it for uffd too, it won't make recvmsg on an fd received from SCM_RIGHTS any less secure than it already is, but it's not exactly an example of robustness in terms of API if it's a program's fault if it doesn't follow every recvmsg with the above quoted check. The ioctl is much more robust because there's no chance that somebody can be attacked by forgetting a specialized non intuitive check after calling the specialized ioctl that installs the fd. Thanks, Andrea