From: Greg KH <gregkh@linuxfoundation.org>
To: asarai@suse.de, crosbymichael@gmail.com, viro@zeniv.linux.org.uk
Cc: stable@vger.kernel.org, stable-commits@vger.kernel.org
Subject: Re: Patch "fs: exec: apply CLOEXEC before changing dumpable task flags" has been added to the 4.4-stable tree
Date: Wed, 4 Jan 2017 11:15:04 +0100 [thread overview]
Message-ID: <20170104101504.GA10978@kroah.com> (raw)
In-Reply-To: <148352436919984@kroah.com>
On Wed, Jan 04, 2017 at 11:06:09AM +0100, gregkh@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> fs: exec: apply CLOEXEC before changing dumpable task flags
>
> to the 4.4-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
> fs-exec-apply-cloexec-before-changing-dumpable-task-flags.patch
> and it can be found in the queue-4.4 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
Oops, no, this version breaks the build, I had to drop it...
greg k-h
>
>
> >From 613cc2b6f272c1a8ad33aefa21cad77af23139f7 Mon Sep 17 00:00:00 2001
> From: Aleksa Sarai <asarai@suse.de>
> Date: Wed, 21 Dec 2016 16:26:24 +1100
> Subject: fs: exec: apply CLOEXEC before changing dumpable task flags
>
> From: Aleksa Sarai <asarai@suse.de>
>
> commit 613cc2b6f272c1a8ad33aefa21cad77af23139f7 upstream.
>
> If you have a process that has set itself to be non-dumpable, and it
> then undergoes exec(2), any CLOEXEC file descriptors it has open are
> "exposed" during a race window between the dumpable flags of the process
> being reset for exec(2) and CLOEXEC being applied to the file
> descriptors. This can be exploited by a process by attempting to access
> /proc/<pid>/fd/... during this window, without requiring CAP_SYS_PTRACE.
>
> The race in question is after set_dumpable has been (for get_link,
> though the trace is basically the same for readlink):
>
> [vfs]
> -> proc_pid_link_inode_operations.get_link
> -> proc_pid_get_link
> -> proc_fd_access_allowed
> -> ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
>
> Which will return 0, during the race window and CLOEXEC file descriptors
> will still be open during this window because do_close_on_exec has not
> been called yet. As a result, the ordering of these calls should be
> reversed to avoid this race window.
>
> This is of particular concern to container runtimes, where joining a
> PID namespace with file descriptors referring to the host filesystem
> can result in security issues (since PRCTL_SET_DUMPABLE doesn't protect
> against access of CLOEXEC file descriptors -- file descriptors which may
> reference filesystem objects the container shouldn't have access to).
>
> Cc: dev@opencontainers.org
> Reported-by: Michael Crosby <crosbymichael@gmail.com>
> Signed-off-by: Aleksa Sarai <asarai@suse.de>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> fs/exec.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -19,7 +19,7 @@
> * current->executable is only used by the procfs. This allows a dispatch
> * table to check for several different types of binary formats. We keep
> * trying until we recognize the file or we run out of supported binary
> - * formats.
> + * formats.
> */
>
> #include <linux/slab.h>
> @@ -1114,6 +1114,13 @@ int flush_old_exec(struct linux_binprm *
> flush_thread();
> current->personality &= ~bprm->per_clear;
>
> + /*
> + * We have to apply CLOEXEC before we change whether the process is
> + * dumpable (in setup_new_exec) to avoid a race with a process in userspace
> + * trying to access the should-be-closed file descriptors of a process
> + * undergoing exec(2).
> + */
> + do_close_on_exec(current->files);
> return 0;
>
> out:
> @@ -1176,7 +1183,6 @@ void setup_new_exec(struct linux_binprm
> group */
> current->self_exec_id++;
> flush_signal_handlers(current, 0);
> - do_close_on_exec(current->files);
> }
> EXPORT_SYMBOL(setup_new_exec);
>
>
>
> Patches currently in stable-queue which might be from asarai@suse.de are
>
> queue-4.4/fs-exec-apply-cloexec-before-changing-dumpable-task-flags.patch
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-01-04 10:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 10:06 Patch "fs: exec: apply CLOEXEC before changing dumpable task flags" has been added to the 4.4-stable tree gregkh
2017-01-04 10:15 ` Greg KH [this message]
2017-01-04 10:34 ` Greg KH
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=20170104101504.GA10978@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=asarai@suse.de \
--cc=crosbymichael@gmail.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.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 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.