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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 750FFC433E0 for ; Tue, 19 May 2020 19:46:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5505C2075F for ; Tue, 19 May 2020 19:46:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="FlcR34Mz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727046AbgESTqW (ORCPT ); Tue, 19 May 2020 15:46:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726333AbgESTqV (ORCPT ); Tue, 19 May 2020 15:46:21 -0400 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E8F2C08C5C2 for ; Tue, 19 May 2020 12:46:20 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id w19so304474ply.11 for ; Tue, 19 May 2020 12:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Q3Ivtwo+9O98WnhcJnwaFt95/Hwxgd+0h4XCSucwWQ0=; b=FlcR34MzrEghbl3vy0OL8MTgoR2QS5ql+EgOS6TLT9J/mjNPWyw1q/1x/GPc6spBVR zIBXeYd140wKdDH6I1j0BK7rPSzWRoIAU5pL+ymoblh8j7HDhXPXdrRuwb4KU4RHbbCX IkV25J7JchNWKWg80zDSG2ZDnZvColidCwd38= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Q3Ivtwo+9O98WnhcJnwaFt95/Hwxgd+0h4XCSucwWQ0=; b=Ua4ynFoap0KSUSpgxipXTl7yJxf/pC/6Tzvr12yn0FAhKVi9b+u/LUeD6tjewAbZQ/ J6yObqPeQV7xcv7iWgEewLeCKdeJrm++pwH3bhDjDh+b1SMADN7/OvZKBwFooGeOClEZ gCJQn2eSpx+ZfvwyhGOtQy/7K6B3z0DzrqsQzghtFtBIeOP3//6U59ALkIxDVqz5SBdc pVua94WKFUCWGuP5JFexDTaPuh2fiWTAsOBTOjVvvspAwR32CwpzmvJNF1C81wW73UhZ dSlUysAZum14WY5uIl9pF3tqur4pB6Pf3mEI/+cu7UFS5zwxoN4vhwRYVC5FBU/GVhAu yzPA== X-Gm-Message-State: AOAM533v/K5Ni5NdQtzYTT+6wZDKrzm25Xo/U0z0PEj3RghJv+7zA4ht mDRmKikdOVD38lLPp/jHlZlmog== X-Google-Smtp-Source: ABdhPJzdXNjb2gwJKNeMLT5AEIU9DnLXEYFye7s+DenXWUh8I4fQdMy4wmHogqrZPX7U/5jAByEZOA== X-Received: by 2002:a17:90a:2ac2:: with SMTP id i2mr1186297pjg.80.1589917579552; Tue, 19 May 2020 12:46:19 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id fw4sm288758pjb.31.2020.05.19.12.46.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2020 12:46:18 -0700 (PDT) Date: Tue, 19 May 2020 12:46:17 -0700 From: Kees Cook To: "Eric W. Biederman" Cc: linux-kernel@vger.kernel.org, Linus Torvalds , Oleg Nesterov , Jann Horn , Greg Ungerer , Rob Landley , Bernd Edlinger , linux-fsdevel@vger.kernel.org, Al Viro , Alexey Dobriyan , Andrew Morton , Casey Schaufler , linux-security-module@vger.kernel.org, James Morris , "Serge E. Hallyn" , Andy Lutomirski Subject: Re: [PATCH v2 7/8] exec: Generic execfd support Message-ID: <202005191220.2DB7B7C7@keescook> References: <87h7wujhmz.fsf@x220.int.ebiederm.org> <87sgga6ze4.fsf@x220.int.ebiederm.org> <87v9l4zyla.fsf_-_@x220.int.ebiederm.org> <877dx822er.fsf_-_@x220.int.ebiederm.org> <87y2poyd91.fsf_-_@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y2poyd91.fsf_-_@x220.int.ebiederm.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 18, 2020 at 07:33:46PM -0500, Eric W. Biederman wrote: > > Most of the support for passing the file descriptor of an executable > to an interpreter already lives in the generic code and in binfmt_elf. > Rework the fields in binfmt_elf that deal with executable file > descriptor passing to make executable file descriptor passing a first > class concept. > > Move the fd_install from binfmt_misc into begin_new_exec after the new > creds have been installed. This means that accessing the file through > /proc//fd/N is able to see the creds for the new executable > before allowing access to the new executables files. > > Performing the install of the executables file descriptor after > the point of no return also means that nothing special needs to > be done on error. The exiting of the process will close all > of it's open files. > > Move the would_dump from binfmt_misc into begin_new_exec right > after would_dump is called on the bprm->file. This makes it > obvious this case exists and that no nesting of bprm->file is > currently supported. > > In binfmt_misc the movement of fd_install into generic code means > that it's special error exit path is no longer needed. > > Signed-off-by: "Eric W. Biederman" Yes, this is so much nicer. :) My head did spin a little between changing the management of bprm->executable between this patch and the next, but I'm okay now. ;) Reviewed-by: Kees Cook nits/thoughts below... > [...] > diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h > index 8c7779d6bf19..653508b25815 100644 > --- a/include/linux/binfmts.h > +++ b/include/linux/binfmts.h > [...] > @@ -48,6 +51,7 @@ struct linux_binprm { > unsigned int taso:1; > #endif > unsigned int recursion_depth; /* only for search_binary_handler() */ > + struct file * executable; /* Executable to pass to the interpreter */ > struct file * file; > struct cred *cred; /* new credentials */ nit: can we fix the "* " stuff here? This should be *file and *executable. > [...] > @@ -69,10 +73,6 @@ struct linux_binprm { > #define BINPRM_FLAGS_ENFORCE_NONDUMP_BIT 0 > #define BINPRM_FLAGS_ENFORCE_NONDUMP (1 << BINPRM_FLAGS_ENFORCE_NONDUMP_BIT) > > -/* fd of the binary should be passed to the interpreter */ > -#define BINPRM_FLAGS_EXECFD_BIT 1 > -#define BINPRM_FLAGS_EXECFD (1 << BINPRM_FLAGS_EXECFD_BIT) > - > /* filename of the binary will be inaccessible after exec */ > #define BINPRM_FLAGS_PATH_INACCESSIBLE_BIT 2 > #define BINPRM_FLAGS_PATH_INACCESSIBLE (1 << BINPRM_FLAGS_PATH_INACCESSIBLE_BIT) nit: may as well renumber BINPRM_FLAGS_PATH_INACCESSIBLE_BIT to 1, they're not UAPI. And, actually, nothing uses the *_BIT defines, so probably the entire chunk of code could just be reduced to: /* either interpreter or executable was unreadable */ #define BINPRM_FLAGS_ENFORCE_NONDUMP BIT(0) /* filename of the binary will be inaccessible after exec */ #define BINPRM_FLAGS_PATH_INACCESSIBLE BIT(1) Though frankly, I wonder if interp_flags could just be removed in favor of two new bit members, especially since interp_data is gone: + /* Either interpreter or executable was unreadable. */ + nondumpable:1; + /* Filename of the binary will be inaccessible after exec. */ + path_inaccessible:1; ... - unsigned interp_flags; ...etc -- Kees Cook