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 906E3C43331 for ; Thu, 7 Nov 2019 19:28:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6936521882 for ; Thu, 7 Nov 2019 19:28:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YqhmYVEW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726733AbfKGT2E (ORCPT ); Thu, 7 Nov 2019 14:28:04 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:58679 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726485AbfKGT2D (ORCPT ); Thu, 7 Nov 2019 14:28:03 -0500 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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