From: Solar Designer <solar@openwall.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Djalal Harouni <tixxdz@opendz.org>,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Alexey Dobriyan <adobriyan@gmail.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Vasiliy Kulikov <segoon@openwall.com>,
Kees Cook <keescook@chromium.org>,
WANG Cong <xiyou.wangcong@gmail.com>,
James Morris <james.l.morris@oracle.com>,
Oleg Nesterov <oleg@redhat.com>,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Greg KH <gregkh@linuxfoundation.org>, Ingo Molnar <mingo@elte.hu>,
Stephen Wilson <wilsons@start.ca>,
"Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: exec_id protection from bad child exit signals (was: Re: [PATCH 0/9] proc: protect /proc/<pid>/* files across execve)
Date: Sun, 11 Mar 2012 14:35:32 +0400 [thread overview]
Message-ID: <20120311103532.GA26980@openwall.com> (raw)
In-Reply-To: <CA+55aFwdOgt=C52APPyvnAitcWNbzu-uXRi43m4bLS85oDgtqA@mail.gmail.com>
On Sat, Mar 10, 2012 at 04:01:09PM -0800, Linus Torvalds wrote:
> I would in general suggest strongly against using exec_id for anything
> that involves files. It isn't designed for that, it's designed for the
> whole "check the parent exec_id" thing for ptrace, where that whole
> "pass things around to another process" approach doesn't work.
Actually, the original/historical purpose of the exec_id stuff was to
protect privileged parent processes (those having done a SUID/SGID exec)
from non-standard child exit signals, which could be set with clone().
I think we may want to audit the current implementation and see if it
still fully achieves the goal or maybe not (and fix it if not).
IIRC, 32 bits was considered enough because it was only the trusted
privileged parent process itself that could potentially cause a
wraparound. (I did not verify this conclusion now. It might be wrong.)
I include below pieces of the prototype implementation from
linux-2.2.12-ow6.tar.gz released in 1999. One notable difference from
the code that went into mainline kernels was that I only incremented the
counter on privileged execve(), and I additionally handled counter
wraparound. I am a bit concerned that a wraparound attack might be
possible on the code currently in mainline kernels, thereby allowing for
a bad exit signal to be sent to a privileged new parent program. Does
anything prevent the wraparound attack currently? (I did not check for
this yet, sorry.)
On exec:
+ bprm->priv_change = id_change || cap_raised;
+ if (bprm->priv_change) {
...
+ /*
+ * Increment the privileged execution counter, so that our
+ * old children know not to send bad exit_signal's to us.
+ * Also, wait on the lock if there's an exit_signal being
+ * sent to us now, to make sure it doesn't get sent to the
+ * new privileged program.
+ */
+ spin_lock_irqsave(¤t->priv_lock, flags);
+ if (!++current->priv) {
+ struct task_struct *p;
+
+ /*
+ * The counter can't really overflow with real-world
+ * programs (and it has to be the privileged program
+ * itself that causes the overflow), but we handle
+ * this case anyway, just for correctness.
+ */
+ read_lock(&tasklist_lock);
+ for_each_task(p) {
+ if (p->p_pptr == current) {
+ p->ppriv = 0;
+ current->priv = 1;
+ }
+ }
+ read_unlock(&tasklist_lock);
+ }
+ spin_unlock_irqrestore(¤t->priv_lock, flags);
In task_struct:
+/* Privileged execution counters, for exit_signal permission checking */
+ spinlock_t priv_lock;
+ int priv, ppriv;
On fork() and clone():
+ spin_lock_init(&p->priv_lock);
+ p->priv = 0;
+ p->ppriv = current->priv;
Exit signal:
+ unsigned long flags = 0;
+ int locked = 0;
+
+ if (sig && sig != SIGCHLD) {
+ /*
+ * Make sure our parent hasn't executed a privileged program
+ * (such as, SUID) since we were born.
+ *
+ * We do some locking here to ensure that there's no race
+ * between the check and actually sending the signal.
+ * Currently, this is probably redundant as notify_parent()
+ * is only used either with the big lock obtained, or with
+ * the signal set to SIGCHLD.
+ */
+ locked = 1;
+ spin_lock_irqsave(&tsk->p_pptr->priv_lock, flags);
+ if (tsk->p_pptr->priv != tsk->ppriv) {
+ spin_unlock_irqrestore(&tsk->p_pptr->priv_lock, flags);
+ locked = 0;
+ sig = 0;
+ }
+ }
...
+ if (locked) spin_unlock_irqrestore(&tsk->p_pptr->priv_lock, flags);
IIRC, an equivalent of the above went upstream (with simplifications
and a variables rename by Alan) in 2.2.13, so that may be another
"reference implementation" to check against.
Alexander
next prev parent reply other threads:[~2012-03-11 10:35 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-10 23:25 [PATCH 0/9] proc: protect /proc/<pid>/* files across execve Djalal Harouni
2012-03-10 23:25 ` [PATCH 1/9] exec: add a global execve counter Djalal Harouni
2012-03-11 0:12 ` Linus Torvalds
2012-03-11 0:36 ` Linus Torvalds
2012-03-11 0:58 ` Linus Torvalds
2012-03-11 8:24 ` Solar Designer
2012-03-11 9:56 ` Ingo Molnar
2012-03-11 14:03 ` Alan Cox
2012-03-11 17:15 ` Djalal Harouni
2012-03-11 8:39 ` Djalal Harouni
2012-03-11 9:40 ` Solar Designer
2012-03-11 17:25 ` Oleg Nesterov
2012-03-11 17:49 ` self_exec_id/parent_exec_id && CLONE_PARENT Oleg Nesterov
2012-03-11 18:02 ` Linus Torvalds
2012-03-11 18:37 ` richard -rw- weinberger
2012-03-11 18:39 ` Oleg Nesterov
2012-03-14 18:55 ` [PATCH 0/1] (Was: self_exec_id/parent_exec_id && CLONE_PARENT) Oleg Nesterov
2012-03-14 18:55 ` [PATCH 1/1] CLONE_PARENT shouldn't allow to set ->exit_signal Oleg Nesterov
2012-03-18 18:25 ` Linus Torvalds
2012-03-18 20:53 ` Oleg Nesterov
2012-03-11 22:48 ` [PATCH 1/9] exec: add a global execve counter Linus Torvalds
2012-03-11 23:32 ` Djalal Harouni
2012-03-11 23:42 ` Linus Torvalds
2012-03-12 0:25 ` Djalal Harouni
2012-03-12 10:11 ` Linus Torvalds
2012-03-12 14:01 ` Djalal Harouni
2012-03-11 23:36 ` Djalal Harouni
2012-03-12 14:34 ` Oleg Nesterov
2012-03-10 23:25 ` [PATCH 2/9] proc: add proc_file_private struct to store private information Djalal Harouni
2012-03-10 23:25 ` [PATCH 3/9] proc: new proc_exec_id_ok() helper function Djalal Harouni
2012-03-10 23:25 ` [PATCH 4/9] proc: protect /proc/<pid>/* INF files from reader across execve Djalal Harouni
2012-03-10 23:25 ` [PATCH 5/9] proc: add protection support for /proc/<pid>/* ONE files Djalal Harouni
2012-03-10 23:25 ` [PATCH 6/9] proc: protect /proc/<pid>/* ONE files from reader across execve Djalal Harouni
2012-03-10 23:25 ` [PATCH 7/9] proc: protect /proc/<pid>/{maps,smaps,numa_maps} Djalal Harouni
2012-03-10 23:25 ` [PATCH 8/9] proc: protect /proc/<pid>/{environ,pagemap} across execve Djalal Harouni
2012-03-11 8:05 ` Alexey Dobriyan
2012-03-11 17:01 ` Djalal Harouni
2012-03-10 23:25 ` [PATCH 9/9] proc: improve and clean up /proc/<pid>/mem protection Djalal Harouni
2012-03-11 0:01 ` [PATCH 0/9] proc: protect /proc/<pid>/* files across execve Linus Torvalds
2012-03-11 0:27 ` Djalal Harouni
2012-03-11 8:46 ` Djalal Harouni
2012-03-11 10:35 ` Solar Designer [this message]
2012-03-11 18:20 ` exec_id protection from bad child exit signals (was: Re: [PATCH 0/9] proc: protect /proc/<pid>/* files across execve) Oleg Nesterov
2012-03-12 19:13 ` [PATCH 0/9] proc: protect /proc/<pid>/* files across execve Eric W. Biederman
2012-03-12 20:44 ` Djalal Harouni
2012-03-12 21:47 ` Eric W. Biederman
2012-03-12 22:41 ` Djalal Harouni
2012-03-12 23:10 ` Eric W. Biederman
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=20120311103532.GA26980@openwall.com \
--to=solar@openwall.com \
--cc=Jason@zx2c4.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=james.l.morris@oracle.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=segoon@openwall.com \
--cc=tixxdz@opendz.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wilsons@start.ca \
--cc=xiyou.wangcong@gmail.com \
/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).