On Tue, Jun 09, 2020 at 10:27:54PM -0700, Kees Cook wrote:
> On Tue, Jun 09, 2020 at 11:27:30PM +0200, Christian Brauner wrote:
> > On June 9, 2020 10:55:42 PM GMT+02:00, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> > >LOL. And while we were debating this, hch just went and cleaned stuff up:
> > >
> > >2618d530dd8b ("net/scm: cleanup scm_detach_fds")
> > >
> > >So, um, yeah, now my proposal is actually even closer to what we already
> > >have there. We just add the replace_fd() logic to __scm_install_fd() and
> > >we're done with it.
> >
> > Cool, you have a link? :)
>
> How about this:
>
Thank you.
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=devel/seccomp/addfd/v3.1&id=bb94586b9e7cc88e915536c2e9fb991a97b62416
>
> --
> Kees Cook
+ if (ufd) {
+ error = put_user(new_fd, ufd);
+ if (error) {
+ put_unused_fd(new_fd);
+ return error;
+ }
+ }
I'm fairly sure this introduces a bug[1] if the user does:
struct msghdr msg = {};
struct cmsghdr *cmsg;
struct iovec io = {
.iov_base = &c,
.iov_len = 1,
};
msg.msg_iov = &io;
msg.msg_iovlen = 1;
msg.msg_control = NULL;
msg.msg_controllen = sizeof(buf);
recvmsg(sock, &msg, 0);
They will have the FD installed, no error message, but FD number wont be written
to memory AFAICT. If two FDs are passed, you will get an efault. They will both
be installed, but memory wont be written to. Maybe instead of 0, make it a
poison pointer, or -1 instead?
-----
As an aside, all of this junk should be dropped:
+ ret = get_user(size, &uaddfd->size);
+ if (ret)
+ return ret;
+
+ ret = copy_struct_from_user(&addfd, sizeof(addfd), uaddfd, size);
+ if (ret)
+ return ret;
and the size member of the seccomp_notif_addfd struct. I brought this up
off-list with Tycho that ioctls have the size of the struct embedded in them. We
should just use that. The ioctl definition is based on this[2]:
#define _IOC(dir,type,nr,size) \
(((dir) << _IOC_DIRSHIFT) | \
((type) << _IOC_TYPESHIFT) | \
((nr) << _IOC_NRSHIFT) | \
((size) << _IOC_SIZESHIFT))
We should just use copy_from_user for now. In the future, we can either
introduce new ioctl names for new structs, or extract the size dynamically from
the ioctl (and mask it out on the switch statement in seccomp_notify_ioctl.
----
+#define SECCOMP_IOCTL_NOTIF_ADDFD SECCOMP_IOR(3, \
+ struct seccomp_notif_addfd)
Lastly, what I believe to be a small mistake, it should be SECCOMP_IOW, based on
the documentation in ioctl.h -- "_IOW means userland is writing and kernel is
reading."
[1]: https://lore.kernel.org/lkml/20200604052040.GA16501@ircssh-2.c.rugged-nimbus-611.internal/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/ioctl.h?id=v5.7#n69
