Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp205285imm; Thu, 27 Sep 2018 19:21:39 -0700 (PDT) X-Google-Smtp-Source: ACcGV61PTGemF1jvyEpGx462lnnwbyS8mS/ZHwkvMGqvoNNEU1o6q9f4zLNmgW9olt2xqyig/wRD X-Received: by 2002:a17:902:aa47:: with SMTP id c7-v6mr14129357plr.100.1538101299745; Thu, 27 Sep 2018 19:21:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538101299; cv=none; d=google.com; s=arc-20160816; b=SECaQZmx2I6C+nahEHRIKcoxVi6h4x1Pqqzj6wtvhJe8yNS11QjYQAXnUGpINnLAqI jauROAGpIvxqZhlgA74juu7Yg5byGCCDFGaIuSizH/tx4BFjizkiui5k0T+mZjxMokGP G7E8FL5zVcy3awHJu0/arjd4JLb4+pIrLZ3Tphcz3GD4R2n0tBkfEpuJN7clAEowKQ0e OJCfqzVz8qy77hVdLFJFDRh8U8lGBdgu29gGbHcYV6ard/JOPQ7Eix6Ww/ZRXYTs4MAx y+VGfDhDqoPXlq8C9RweA0kMDZkK9qxu5K+DK6khWwNXy9xAdzkLToLVvTU7cQQAGqfC fBCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=GOKsD+KchkBKgT7nKYt8vN7PSnsq+jSh5jm3e7+wpnk=; b=HbkoThJ8Tk8zcJZ53SiY7T6EIplfl8TDEXPVKGlRcGkMUhe2J4HBWb4Fe6jZHNitQS qXXAE6OCE2WS+6jgrYLtKnCE/tEADby4rtfh0zdtj3lK135mwMEGcReo102BPXbVsh7j tSbZAnPegCGYGO3sg5UXGO8R+5rhEFx/GR2OKqIUA0JqCiuhPcrkRzRRiBIzWWF/pBIf G42U+2EkMCWsEpHSaOlcr64fzVtewQWwXEh2U/DrdjGF0OloqNseqYpT0vE1A9QZ6drS SxcSWmGO1i4lpLfAy6geHEQ4vlZrdsw8+Wt4Do6/s/a6RLkl6QgZa+IOqCweVLUz9dEE a2Fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=MCal4byR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q90-v6si3820323pfa.272.2018.09.27.19.21.21; Thu, 27 Sep 2018 19:21:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=MCal4byR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728745AbeI1ImS (ORCPT + 99 others); Fri, 28 Sep 2018 04:42:18 -0400 Received: from mail-yb1-f195.google.com ([209.85.219.195]:45995 "EHLO mail-yb1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726271AbeI1ImR (ORCPT ); Fri, 28 Sep 2018 04:42:17 -0400 Received: by mail-yb1-f195.google.com with SMTP id d9-v6so1999159ybr.12 for ; Thu, 27 Sep 2018 19:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GOKsD+KchkBKgT7nKYt8vN7PSnsq+jSh5jm3e7+wpnk=; b=MCal4byRTXIKai+bi5VIh3R1hnr287+fnSCdFsttGGiZwRkV7LHJAL9e091vAptRJK MzK1H7ObIIQPoKB0XZcb9F3EgAw+46NK3la1ibqO6tV08LtRClFoUe/MIK8/o+KQtuwD oJl1vHTXM2OFhHBLzmGolFW//G6V002dE7/tY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GOKsD+KchkBKgT7nKYt8vN7PSnsq+jSh5jm3e7+wpnk=; b=XxeaeVuvdrTvErsE64a9Sf77Ex5u5tKlE/B4LZyf2tnEUL+h1sg+6ymKrUIaE90Czb t4y1C+APylWssGgfwCGUkm6h6tYk9G9sYNyLfBvw4HaqNc3kNgqJdOg6wSfBKr1xy6bF YrNL+Wq7E3QirOdq+2ZBnMjTPQOqWGIRKsHXAqx+EZ++s7TJJNU8sTuewnXAVmzMsABo e8fWLtnOCNHmzaZkqHdak4uzSMVSB960j7kopHunMos1DNnV1kWEBZjb8NsqFug8wsNz VR1LHp65+j1ciOaRY0eONqY/AHCHARIi5Yck5YJXygjD4VpZueRN5YSswJcLNHxplJba muyQ== X-Gm-Message-State: ABuFfoiLS786y5zp/71D8L0mENAJNFOZGY3a6wOx3cm1uzq3XoYF0kVy AL+NghHmNM+LSJI8PMAsmCJCNhSZXaQ= X-Received: by 2002:a25:2d58:: with SMTP id s24-v6mr7497235ybe.347.1538101253800; Thu, 27 Sep 2018 19:20:53 -0700 (PDT) Received: from mail-yw1-f46.google.com (mail-yw1-f46.google.com. [209.85.161.46]) by smtp.gmail.com with ESMTPSA id b7-v6sm3147888ywe.1.2018.09.27.19.20.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 19:20:52 -0700 (PDT) Received: by mail-yw1-f46.google.com with SMTP id y14-v6so1997225ywa.4 for ; Thu, 27 Sep 2018 19:20:51 -0700 (PDT) X-Received: by 2002:a0d:fec6:: with SMTP id o189-v6mr6906088ywf.237.1538101251463; Thu, 27 Sep 2018 19:20:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d116:0:0:0:0:0 with HTTP; Thu, 27 Sep 2018 19:20:50 -0700 (PDT) In-Reply-To: References: <20180927151119.9989-1-tycho@tycho.ws> <20180927151119.9989-5-tycho@tycho.ws> From: Kees Cook Date: Thu, 27 Sep 2018 19:20:50 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 4/6] files: add a replace_fd_files() function To: Tycho Andersen Cc: LKML , Linux Containers , Linux API , Andy Lutomirski , Oleg Nesterov , "Eric W . Biederman" , "Serge E . Hallyn" , Christian Brauner , Tyler Hicks , Akihiro Suda , Jann Horn , "linux-fsdevel@vger.kernel.org" , Alexander Viro Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 27, 2018 at 2:59 PM, Kees Cook wrote: > On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote: >> Similar to fd_install/__fd_install, we want to be able to replace an fd of >> an arbitrary struct files_struct, not just current's. We'll use this in the >> next patch to implement the seccomp ioctl that allows inserting fds into a >> stopped process' context. >> >> v7: new in v7 >> >> Signed-off-by: Tycho Andersen >> CC: Alexander Viro >> CC: Kees Cook >> CC: Andy Lutomirski >> CC: Oleg Nesterov >> CC: Eric W. Biederman >> CC: "Serge E. Hallyn" >> CC: Christian Brauner >> CC: Tyler Hicks >> CC: Akihiro Suda >> --- >> fs/file.c | 22 +++++++++++++++------- >> include/linux/file.h | 8 ++++++++ >> 2 files changed, 23 insertions(+), 7 deletions(-) >> >> diff --git a/fs/file.c b/fs/file.c >> index 7ffd6e9d103d..3b3c5aadaadb 100644 >> --- a/fs/file.c >> +++ b/fs/file.c >> @@ -850,24 +850,32 @@ __releases(&files->file_lock) >> } >> >> int replace_fd(unsigned fd, struct file *file, unsigned flags) >> +{ >> + return replace_fd_task(current, fd, file, flags); >> +} >> + >> +/* >> + * Same warning as __alloc_fd()/__fd_install() here. >> + */ >> +int replace_fd_task(struct task_struct *task, unsigned fd, >> + struct file *file, unsigned flags) >> { >> int err; >> - struct files_struct *files = current->files; > > Same feedback as Jann: on a purely "smaller diff" note, this could > just be s/current/task/ here and all the other s/files/task->files/ > would go away... > >> >> if (!file) >> - return __close_fd(files, fd); >> + return __close_fd(task->files, fd); >> >> - if (fd >= rlimit(RLIMIT_NOFILE)) >> + if (fd >= task_rlimit(task, RLIMIT_NOFILE)) >> return -EBADF; >> >> - spin_lock(&files->file_lock); >> - err = expand_files(files, fd); >> + spin_lock(&task->files->file_lock); >> + err = expand_files(task->files, fd); >> if (unlikely(err < 0)) >> goto out_unlock; >> - return do_dup2(files, file, fd, flags); >> + return do_dup2(task->files, file, fd, flags); >> >> out_unlock: >> - spin_unlock(&files->file_lock); >> + spin_unlock(&task->files->file_lock); >> return err; >> } >> >> diff --git a/include/linux/file.h b/include/linux/file.h >> index 6b2fb032416c..f94277fee038 100644 >> --- a/include/linux/file.h >> +++ b/include/linux/file.h >> @@ -11,6 +11,7 @@ >> #include >> >> struct file; >> +struct task_struct; >> >> extern void fput(struct file *); >> >> @@ -79,6 +80,13 @@ static inline void fdput_pos(struct fd f) >> >> extern int f_dupfd(unsigned int from, struct file *file, unsigned flags); >> extern int replace_fd(unsigned fd, struct file *file, unsigned flags); >> +/* >> + * Warning! This is only safe if you know the owner of the files_struct is >> + * stopped outside syscall context. It's a very bad idea to use this unless you >> + * have similar guarantees in your code. >> + */ >> +extern int replace_fd_task(struct task_struct *task, unsigned fd, >> + struct file *file, unsigned flags); > > Perhaps call this __replace_fd() to indicate the "please don't use > this unless you're very sure"ness of it? > >> extern void set_close_on_exec(unsigned int fd, int flag); >> extern bool get_close_on_exec(unsigned int fd); >> extern int get_unused_fd_flags(unsigned flags); >> -- >> 2.17.1 >> > > If I can get an Ack from Al, that would be very nice. :) In out-of-band feedback from Al, he's pointed out a much cleaner approach: do the work on the "current" side. i.e. current is stopped in __seccomp_filter in the case SECCOMP_RET_USER_NOTIFY. Instead of having the ioctl-handing process doing the work, have it done on the other side. This may cause some additional complexity on the ioctl return path, but it solves both this problem and the "ptrace attach" issue: have the work delayed until "current" gets caught by seccomp. -Kees -- Kees Cook Pixel Security