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 3444DC43331 for ; Thu, 7 Nov 2019 18:23:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E1537206DF for ; Thu, 7 Nov 2019 18:23:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="N3A7ncOL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E1537206DF 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 943CD6B0005; Thu, 7 Nov 2019 13:23:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F4146B0007; Thu, 7 Nov 2019 13:23:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80ACB6B0008; Thu, 7 Nov 2019 13:23:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 6B3856B0005 for ; Thu, 7 Nov 2019 13:23:10 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 1D5CE4995F5 for ; Thu, 7 Nov 2019 18:23:10 +0000 (UTC) X-FDA: 76130303340.15.top13_8fee23b3e933d X-HE-Tag: top13_8fee23b3e933d X-Filterd-Recvd-Size: 6583 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 18:23:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573150988; 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=KubHtV049K2BSRPzUIF8otGa4rwY4O8d8+SI2Kib58I=; b=N3A7ncOL20QyrB2L0VPmR9EhOPpSuwSm8qGMMjVrNZ87gsgiuRZVH+7TvUDxBomueOh9+q wtDLhJgRzXuFG7JifUafubvst7laslTah6vSf+Ia3cLKmDyb0a3qHq9jhliRFDkObTpvh5 Zq8bcLcTUTvekicBnm7EoaI8qrofLhQ= 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-375-H1N7h4BROg-xZsGGE_44Kg-1; Thu, 07 Nov 2019 13:23:04 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DEE27800C61; Thu, 7 Nov 2019 18:23:00 +0000 (UTC) Received: from mail (ovpn-121-157.rdu2.redhat.com [10.10.121.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 919F9600D3; Thu, 7 Nov 2019 18:23:00 +0000 (UTC) Date: Thu, 7 Nov 2019 13:22:59 -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: <20191107182259.GK17896@redhat.com> References: <1572967777-8812-1-git-send-email-rppt@linux.ibm.com> <1572967777-8812-2-git-send-email-rppt@linux.ibm.com> <20191105162424.GH30717@redhat.com> <20191107083902.GB3247@linux.ibm.com> <20191107153801.GF17896@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.11 X-MC-Unique: H1N7h4BROg-xZsGGE_44Kg-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 08:15:53AM -0800, Daniel Colascione wrote: > You're already paying for bounds checking. Receiving a message via a > datagram socket is basically the same thing as what UFFD's read is > doing anyway. Except it's synchronous and there are no dynamic allocations required in uffd, while af_netlink and af_unix both all deal with queue of events in skbs dynamically allocated. Ultimately if we strip away the skbs for performance reasons, there wouldn't be much code to share, so if the only benefit would be to call recvmsg which would still be as insecure as read for the "worse" case than suid, so I don't see the point. And should then eventfd also become a netlink then? I mean uffd was supposed to work like eventfd except it requires specialized events. > Programs generally don't go calling recvmsg() on random FDs they get > from the outside world. They do call read() on those FDs, which is why That programs generally don't do something only means the attack is less probable. Programs generally aren't suid. Programs generally don't use SCM_RIGHTS. Programs generally don't ignore the retval of open/socket/uffd syscalls. Programs generally don't make assumptions on the fd ID after one of those syscalls that install fds. If all programs generally do the right thing (where the most important is to not make assumptions on the fd IDs and to check all syscall retvals), there was never an issue to begin with even in uffd API. > read() having unexpected side effects is terrible. If having unexpected side effects in read is "terrible" (i.e. I personally prefer to use terms like terrible when there's at least something that can be exploited in practice, not for theoretical issues) for an SCM_RIGHTS receiving daemon, I just don't see how the exact same unexpected (still theoretical) side effects in recvmsg with an unexpected nested cmsg->cmsg_type =3D=3D SCM_RIGHTS message being returned, isn't terrible too. > If you call it with a non-empty ancillary data buffer, you know to > react to what you get. You're *opting into* the possibility of getting > file descriptors. Sure, it's theoretically possible that a program > calls recvmsg on random FDs it gets from unknown sources, sees > SCM_RIGHTS unexpectedly, and just the SCM_RIGHTS message and its FD > payload, but that's an outright bug, while calling read() on stdin is > no bug. I'm not talking about stdin and suid. recvmsg might mitigate the concern for suid (not certain, depends on the suid, if it's generally doing what you expect most suid to be doing or not), I was talking about the SCM_RIGHTS receiving daemon instead, the "worse" more concerning case than the suid. I quote below Andy's relevant email: =3D=3D=3D=3D=3D=3D It's worse if SCM_RIGHTS is involved. =3D=3D=3D=3D=3D=3D 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 */ }