From: ebiederm@xmission.com (Eric W. Biederman)
To: <linux-kernel@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Al Viro <viro@zeniv.linux.org.uk>,
Luis Chamberlain <mcgrof@kernel.org>,
<linux-fsdevel@vger.kernel.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
linux-security-module@vger.kernel.org,
"Serge E. Hallyn" <serge@hallyn.com>,
James Morris <jmorris@namei.org>,
Kentaro Takeda <takedakn@nttdata.co.jp>,
Casey Schaufler <casey@schaufler-ca.com>,
John Johansen <john.johansen@canonical.com>,
Christoph Hellwig <hch@infradead.org>
Subject: [PATCH 5/7] exec: Factor bprm_execve out of do_execve_common
Date: Tue, 14 Jul 2020 08:30:30 -0500 [thread overview]
Message-ID: <878sfm6x6x.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <871rle8bw2.fsf@x220.int.ebiederm.org> (Eric W. Biederman's message of "Tue, 14 Jul 2020 08:27:41 -0500")
Currently it is necessary for the usermode helper code and the code
that launches init to use set_fs so that pages coming from the kernel
look like they are coming from userspace.
To allow that usage of set_fs to be removed cleanly the argument
copying from userspace needs to happen earlier. Factor bprm_execve
out of do_execve_common to separate out the copying of arguments
to the newe stack, and the rest of exec.
In separating bprm_execve from do_execve_common the copying
of the arguments onto the new stack happens earlier.
As the copying of the arguments does not depend any security hooks,
files, the file table, current->in_execve, current->fs->in_exec,
bprm->unsafe, or creds this is safe.
Likewise the security hook security_creds_for_exec does not depend upon
preventing the argument copying from happening.
In addition to making it possible to implement kernel_execve that
performs the copying differently, this separation of bprm_execve from
do_execve_common makes for a nice separation of responsibilities making
the exec code easier to navigate.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
fs/exec.c | 108 +++++++++++++++++++++++++++++-------------------------
1 file changed, 58 insertions(+), 50 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index afb168bf5e23..50508892fa71 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1856,44 +1856,16 @@ static int exec_binprm(struct linux_binprm *bprm)
/*
* sys_execve() executes a new program.
*/
-static int do_execveat_common(int fd, struct filename *filename,
- struct user_arg_ptr argv,
- struct user_arg_ptr envp,
- int flags)
+static int bprm_execve(struct linux_binprm *bprm,
+ int fd, struct filename *filename, int flags)
{
- struct linux_binprm *bprm;
struct file *file;
struct files_struct *displaced;
int retval;
- if (IS_ERR(filename))
- return PTR_ERR(filename);
-
- /*
- * We move the actual failure in case of RLIMIT_NPROC excess from
- * set*uid() to execve() because too many poorly written programs
- * don't check setuid() return code. Here we additionally recheck
- * whether NPROC limit is still exceeded.
- */
- if ((current->flags & PF_NPROC_EXCEEDED) &&
- atomic_read(¤t_user()->processes) > rlimit(RLIMIT_NPROC)) {
- retval = -EAGAIN;
- goto out_ret;
- }
-
- /* We're below the limit (still or again), so we don't want to make
- * further execve() calls fail. */
- current->flags &= ~PF_NPROC_EXCEEDED;
-
- bprm = alloc_bprm(fd, filename);
- if (IS_ERR(bprm)) {
- retval = PTR_ERR(bprm);
- goto out_ret;
- }
-
retval = unshare_files(&displaced);
if (retval)
- goto out_free;
+ return retval;
retval = prepare_bprm_creds(bprm);
if (retval)
@@ -1919,28 +1891,11 @@ static int do_execveat_common(int fd, struct filename *filename,
close_on_exec(fd, rcu_dereference_raw(current->files->fdt)))
bprm->interp_flags |= BINPRM_FLAGS_PATH_INACCESSIBLE;
- retval = prepare_arg_pages(bprm, argv, envp);
- if (retval < 0)
- goto out;
-
/* Set the unchanging part of bprm->cred */
retval = security_bprm_creds_for_exec(bprm);
if (retval)
goto out;
- retval = copy_string_kernel(bprm->filename, bprm);
- if (retval < 0)
- goto out;
-
- bprm->exec = bprm->p;
- retval = copy_strings(bprm->envc, envp, bprm);
- if (retval < 0)
- goto out;
-
- retval = copy_strings(bprm->argc, argv, bprm);
- if (retval < 0)
- goto out;
-
retval = exec_binprm(bprm);
if (retval < 0)
goto out;
@@ -1951,8 +1906,6 @@ static int do_execveat_common(int fd, struct filename *filename,
rseq_execve(current);
acct_update_integrals(current);
task_numa_free(current, false);
- free_bprm(bprm);
- putname(filename);
if (displaced)
put_files_struct(displaced);
return retval;
@@ -1974,6 +1927,61 @@ static int do_execveat_common(int fd, struct filename *filename,
out_files:
if (displaced)
reset_files_struct(displaced);
+
+ return retval;
+}
+
+static int do_execveat_common(int fd, struct filename *filename,
+ struct user_arg_ptr argv,
+ struct user_arg_ptr envp,
+ int flags)
+{
+ struct linux_binprm *bprm;
+ int retval;
+
+ if (IS_ERR(filename))
+ return PTR_ERR(filename);
+
+ /*
+ * We move the actual failure in case of RLIMIT_NPROC excess from
+ * set*uid() to execve() because too many poorly written programs
+ * don't check setuid() return code. Here we additionally recheck
+ * whether NPROC limit is still exceeded.
+ */
+ if ((current->flags & PF_NPROC_EXCEEDED) &&
+ atomic_read(¤t_user()->processes) > rlimit(RLIMIT_NPROC)) {
+ retval = -EAGAIN;
+ goto out_ret;
+ }
+
+ /* We're below the limit (still or again), so we don't want to make
+ * further execve() calls fail. */
+ current->flags &= ~PF_NPROC_EXCEEDED;
+
+ bprm = alloc_bprm(fd, filename);
+ if (IS_ERR(bprm)) {
+ retval = PTR_ERR(bprm);
+ goto out_ret;
+ }
+
+ retval = prepare_arg_pages(bprm, argv, envp);
+ if (retval < 0)
+ goto out_free;
+
+ retval = copy_string_kernel(bprm->filename, bprm);
+ if (retval < 0)
+ goto out_free;
+ bprm->exec = bprm->p;
+
+ retval = copy_strings(bprm->envc, envp, bprm);
+ if (retval < 0)
+ goto out_free;
+
+ retval = copy_strings(bprm->argc, argv, bprm);
+ if (retval < 0)
+ goto out_free;
+
+ retval = bprm_execve(bprm, fd, filename, flags);
out_free:
free_bprm(bprm);
--
2.25.0
next prev parent reply other threads:[~2020-07-14 13:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 13:27 [PATCH 0/7] Implementing kernel_execve Eric W. Biederman
2020-07-14 13:28 ` [PATCH 1/7] exec: Remove unnecessary spaces from binfmts.h Eric W. Biederman
2020-07-14 21:38 ` Kees Cook
2020-07-15 6:28 ` Christoph Hellwig
2020-07-14 13:29 ` [PATCH 2/7] exec: Factor out alloc_bprm Eric W. Biederman
2020-07-14 21:38 ` Kees Cook
2020-07-15 6:30 ` Christoph Hellwig
2020-07-14 13:29 ` [PATCH 3/7] exec: Move initialization of bprm->filename into alloc_bprm Eric W. Biederman
2020-07-14 21:38 ` Kees Cook
2020-07-15 6:34 ` Christoph Hellwig
2020-07-14 13:30 ` [PATCH 4/7] exec: Move bprm_mm_init " Eric W. Biederman
2020-07-14 21:37 ` Kees Cook
2020-07-15 6:35 ` Christoph Hellwig
2020-07-14 13:30 ` Eric W. Biederman [this message]
2020-07-14 21:38 ` [PATCH 5/7] exec: Factor bprm_execve out of do_execve_common Kees Cook
2020-07-15 6:36 ` Christoph Hellwig
2020-07-14 13:31 ` [PATCH 6/7] exec: Factor bprm_stack_limits out of prepare_arg_pages Eric W. Biederman
2020-07-14 21:41 ` Kees Cook
2020-07-15 6:38 ` Christoph Hellwig
2020-07-14 13:31 ` [PATCH 7/7] exec: Implement kernel_execve Eric W. Biederman
2020-07-14 21:49 ` Kees Cook
2020-07-15 6:42 ` Christoph Hellwig
2020-07-15 14:55 ` David Laight
2020-07-15 15:09 ` Kees Cook
2020-07-15 16:46 ` David Laight
2020-07-15 15:00 ` Kees Cook
2020-07-15 18:20 ` Christoph Hellwig
2020-07-15 6:42 ` Christoph Hellwig
2020-07-15 18:23 ` Eric W. Biederman
2020-07-14 15:32 ` [PATCH 0/7] Implementing kernel_execve Linus Torvalds
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=878sfm6x6x.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=bp@alien8.de \
--cc=casey@schaufler-ca.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mcgrof@kernel.org \
--cc=mingo@redhat.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=serge@hallyn.com \
--cc=takedakn@nttdata.co.jp \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).