Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Daniel Colascione <dancol@google.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	 Andy Lutomirski <luto@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Jann Horn <jannh@google.com>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	Lokesh Gidra <lokeshgidra@google.com>,
	 Nick Kralevich <nnk@google.com>, Nosh Minwalla <nosh@google.com>,
	Pavel Emelyanov <ovzxemul@gmail.com>,
	 Tim Murray <timmurray@google.com>,
	Linux API <linux-api@vger.kernel.org>,
	 linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK
Date: Sun, 10 Nov 2019 09:02:45 -0800
Message-ID: <CALCETrWxkzp5mzoqq28cbZLmwYh-k_er-8ocVoLPXXUk66Yprg@mail.gmail.com> (raw)
In-Reply-To: <20191107182259.GK17896@redhat.com>

On Thu, Nov 7, 2019 at 10:23 AM Andrea Arcangeli <aarcange@redhat.com> wrote:
>
> 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.

Not sure what you mean.

>
> And should then eventfd also become a netlink then? I mean uffd was
> supposed to work like eventfd except it requires specialized events.

No. None of this even means that these objects should be sockets per
se.  The point is that anyone who calls recvmsg() and passes a control
buf *must* handle SCM_RIGHTS because even very old Unixes can
materialize file descriptors.  The only exception is if the program
knows a priori that the fd refers to a socket that can't use
SCM_RIGHTS.

In other words, failing to handle file descriptors returned by
recvmsg() is an application bug.  Failing to handle file descriptors
returned by read() is not an application bug -- it's a kernel bug.

> > 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:
>
> ======
> It's worse if SCM_RIGHTS is involved.
> ======
>
> Not all software will do this after calling recvmsg:
>
>     if (cmsg->cmsg_type == 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 */
>     }
>

You've misunderstood what you're quoting me as saying.  I'm saying
that the issue is worse if you pass the userfaultfd via SCM_RIGHTS to
an unsuspecting program.  It is perfectly valid to receive a file
descriptor via SCM_RIGHTS and then call read(), at least so long as
you are okay with potentially blocking.

If you receive a fd to a socket using SCM_RIGHTS and then you fail to
check cmsg_type as above, then you have a bug regardless of
userfaultfd.

--Andy


  parent reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 15:29 [PATCH 0/1] " Mike Rapoport
2019-11-05 15:29 ` [PATCH 1/1] " Mike Rapoport
2019-11-05 15:37   ` Andrea Arcangeli
2019-11-05 15:55   ` Daniel Colascione
2019-11-05 16:00     ` Andy Lutomirski
2019-11-05 16:06       ` Daniel Colascione
2019-11-05 16:33         ` Andrea Arcangeli
2019-11-05 16:39           ` Daniel Colascione
2019-11-05 16:55             ` Andrea Arcangeli
2019-11-05 17:02               ` Daniel Colascione
2019-11-05 17:30                 ` Andrea Arcangeli
2019-11-05 22:01                 ` Andy Lutomirski
2019-11-05 22:10                   ` Daniel Colascione
2019-11-05 16:24       ` Andrea Arcangeli
2019-11-05 16:41         ` Daniel Colascione
2019-11-07  8:39           ` Mike Rapoport
2019-11-07  8:54             ` Daniel Colascione
2019-11-07 15:38               ` Andrea Arcangeli
2019-11-07 16:15                 ` Daniel Colascione
2019-11-07 18:22                   ` Andrea Arcangeli
2019-11-07 18:50                     ` Daniel Colascione
2019-11-07 19:27                       ` Andrea Arcangeli
2019-11-10 17:02                     ` Andy Lutomirski [this message]
2019-11-05 15:59   ` Aleksa Sarai

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALCETrWxkzp5mzoqq28cbZLmwYh-k_er-8ocVoLPXXUk66Yprg@mail.gmail.com \
    --to=luto@kernel.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dancol@google.com \
    --cc=jannh@google.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lokeshgidra@google.com \
    --cc=nnk@google.com \
    --cc=nosh@google.com \
    --cc=ovzxemul@gmail.com \
    --cc=rppt@linux.ibm.com \
    --cc=timmurray@google.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org
	public-inbox-index linux-mm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git