All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Sargun Dhillon <sargun@sargun.me>
Cc: christian.brauner@ubuntu.com,
	containers@lists.linux-foundation.org, cyphar@cyphar.com,
	jannh@google.com, jeffv@google.com, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org, palmer@google.com,
	rsesek@google.com, tycho@tycho.ws,
	Matt Denton <mpdenton@google.com>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v2 2/3] seccomp: Introduce addfd ioctl to seccomp user notifier
Date: Fri, 29 May 2020 19:43:10 -0700	[thread overview]
Message-ID: <202005291926.E9004B4@keescook> (raw)
In-Reply-To: <20200530011054.GA14852@ircssh-2.c.rugged-nimbus-611.internal>

On Sat, May 30, 2020 at 01:10:55AM +0000, Sargun Dhillon wrote:
> // And then SCM reads:
> 	for (i=0, cmfptr=(__force int __user *)CMSG_DATA(cm); i<fdmax;
> 	     i++, cmfptr++)
> 	{
> 		int new_fd;
> 		err = get_unused_fd_flags(MSG_CMSG_CLOEXEC & msg->msg_flags
> 					  ? O_CLOEXEC : 0);
> 		if (err < 0)
> 			break;
> 		new_fd = err;
> 		err = put_user(new_fd, cmfptr);
> 		if (err) {
> 			put_unused_fd(new_fd);
> 			break;
> 		}
> 
> 		err = file_receive(new_fd, fp[i]);
> 		if (err) {
> 			put_unused_fd(new_fd);
> 			break;
> 		}
> 	}
> 
> And our code reads:
> 
> 
> static void seccomp_handle_addfd(struct seccomp_kaddfd *addfd)
> {
> 	int ret, err;
> 
> 	/*
> 	 * Remove the notification, and reset the list pointers, indicating
> 	 * that it has been handled.
> 	 */
> 	list_del_init(&addfd->list);
> 
> 	if (addfd->fd == -1) {
> 		ret = get_unused_fd_flags(addfd->flags);
> 		if (ret < 0)
> 			goto err;
> 
> 		err = file_receive(ret, addfd->file);
> 		if (err) {
> 			put_unused_fd(ret);
> 			ret = err;
> 		}
> 	} else {
> 		ret = file_receive_replace(addfd->fd, addfd->flags,
> 					   addfd->file);
> 	}
> 
> err:
> 	addfd->ret = ret;
> 	complete(&addfd->completion);
> }
> 
> 
> And the pidfd getfd code reads:
> 
> static int pidfd_getfd(struct pid *pid, int fd)
> {
> 	struct task_struct *task;
> 	struct file *file;
> 	int ret, err;
> 
> 	task = get_pid_task(pid, PIDTYPE_PID);
> 	if (!task)
> 		return -ESRCH;
> 
> 	file = __pidfd_fget(task, fd);
> 	put_task_struct(task);
> 	if (IS_ERR(file))
> 		return PTR_ERR(file);
> 
> 	ret = get_unused_fd_flags(O_CLOEXEC);
> 	if (ret >= 0) {
> 		err = file_receive(ret, file);
> 		if (err) {
> 			put_unused_fd(ret);
> 			ret = err;
> 		}
> 	}
> 
> 	fput(file);
> 	return ret;
> }

I mean, yes, that's certainly better, but it just seems a shame that
everyone has to do the get_unused/put_unused dance just because of how
SCM_RIGHTS does this weird put_user() in the middle.

Can anyone clarify the expected failure mode from SCM_RIGHTS? Can we
move the put_user() after instead? I think cleanup would just be:
replace_fd(fd, NULL, 0)

So:

(updated to skip sock updates on failure; thank you Christian!)

int file_receive(int fd, unsigned long flags, struct file *file)
{
	struct socket *sock;
	int ret;

	ret = security_file_receive(file);
	if (ret)
		return ret;

	/* Install the file. */
	if (fd == -1) {
		ret = get_unused_fd_flags(flags);
		if (ret >= 0)
			fd_install(ret, get_file(file));
	} else {
		ret = replace_fd(fd, file, flags);
	}

	/* Bump the sock usage counts. */
	if (ret >= 0) {
		sock = sock_from_file(addfd->file, &err);
		if (sock) {
			sock_update_netprioidx(&sock->sk->sk_cgrp_data);
			sock_update_classid(&sock->sk->sk_cgrp_data);
		}
	}

	return ret;
}

scm_detach_fds()
	...
	for (i=0, cmfptr=(__force int __user *)CMSG_DATA(cm); i<fdmax;
             i++, cmfptr++)
	{
		int new_fd;

		err = file_receive(-1, MSG_CMSG_CLOEXEC & msg->msg_flags
                                          ? O_CLOEXEC : 0, fp[i]);
		if (err < 0)
			break;
		new_fd = err;

		err = put_user(err, cmfptr);
		if (err) {
			/*
			 * If we can't notify userspace that it got the
			 * fd, we need to unwind and remove it again.
			 */
			replace_fd(new_fd, NULL, 0);
			break;
		}
	}
	...



-- 
Kees Cook

  reply	other threads:[~2020-05-30  2:43 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 11:08 [PATCH v2 0/3] Add seccomp notifier ioctl that enables adding fds Sargun Dhillon
2020-05-28 11:08 ` [PATCH v2 1/3] seccomp: Add find_notification helper Sargun Dhillon
2020-05-29  6:23   ` Kees Cook
2020-05-29 17:40     ` Sargun Dhillon
2020-05-29 20:14       ` Kees Cook
2020-05-29  9:57   ` Christian Brauner
2020-05-28 11:08 ` [PATCH v2 2/3] seccomp: Introduce addfd ioctl to seccomp user notifier Sargun Dhillon
2020-05-29  7:31   ` Kees Cook
2020-05-29  7:38     ` Christian Brauner
2020-05-29  7:45       ` Kees Cook
2020-05-30  1:10     ` Sargun Dhillon
2020-05-30  2:43       ` Kees Cook [this message]
2020-05-30  3:17         ` Jann Horn
2020-05-30  5:22           ` Kees Cook
2020-05-30 13:58           ` Christian Brauner
2020-05-30 16:09             ` Kees Cook
2020-05-30  3:58         ` Sargun Dhillon
2020-05-30  5:47           ` Kees Cook
2020-05-30 14:13             ` Christian Brauner
2020-05-30 16:14               ` Kees Cook
2020-05-30 16:21                 ` Christian Brauner
2020-05-30 14:08         ` Al Viro
2020-05-30 16:07           ` Kees Cook
2020-06-01 19:02             ` Sargun Dhillon
2020-06-01 19:59               ` Kees Cook
2020-05-29  9:24   ` Giuseppe Scrivano
2020-05-29 10:32   ` Christian Brauner
2020-05-29 13:31     ` Christian Brauner
2020-05-29 22:35       ` Sargun Dhillon
2020-05-28 11:08 ` [PATCH v2 3/3] selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD Sargun Dhillon
2020-05-29  7:41   ` Kees Cook
2020-05-29 13:29     ` Tycho Andersen
2020-05-29 18:46     ` Sargun Dhillon
2020-05-29 19:12       ` Tycho Andersen
2020-05-29 20:09       ` Kees Cook
2020-05-29 13:30 ` [PATCH v2 0/3] Add seccomp notifier ioctl that enables adding fds Tycho Andersen

Reply instructions:

You may reply publicly 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=202005291926.E9004B4@keescook \
    --to=keescook@chromium.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=cyphar@cyphar.com \
    --cc=jannh@google.com \
    --cc=jeffv@google.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpdenton@google.com \
    --cc=palmer@google.com \
    --cc=rsesek@google.com \
    --cc=sargun@sargun.me \
    --cc=tycho@tycho.ws \
    --cc=viro@zeniv.linux.org.uk \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.