linux-kernel - Re: [PATCH] Yama: allow access for the current ptrace parent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5jKcx028GkcqsDzHBb4iWH-u2_jo5_4SrkB36gb8OpW_Hw@mail.gmail.com>
Date:   Fri, 2 Dec 2016 15:27:46 -0800
From:   Kees Cook <keescook@...omium.org>
To:     James Morris <james.l.morris@...cle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Josh Stone <jistone@...hat.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] Yama: allow access for the current ptrace parent

On Wed, Nov 30, 2016 at 5:24 PM, Josh Stone <jistone@...hat.com> wrote:
> Under ptrace_scope=1, it's possible to have a tracee that is already
> ptrace-attached, but is no longer a direct descendant.  For instance, a
> forking daemon will be re-parented to init, losing its ancestry to the
> tracer that launched it.
>
> The tracer can continue using ptrace in that state, but it will be
> denied other accesses that check PTRACE_MODE_ATTACH, like process_vm_rw
> and various procfs files.  There's no reason to prevent such access for
> a tracer that already has ptrace control anyway.
>
> This patch adds a case to ptracer_exception_found to allow access for
> any task in the same thread group as the current ptrace parent.

Nice catch, thanks!

> Signed-off-by: Josh Stone <jistone@...hat.com>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: James Morris <james.l.morris@...cle.com>
> Cc: "Serge E. Hallyn" <serge@...lyn.com>
> Cc: linux-security-module@...r.kernel.org
> ---
>  security/yama/yama_lsm.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
> index 0309f2111c70..da67a6e07a60 100644
> --- a/security/yama/yama_lsm.c
> +++ b/security/yama/yama_lsm.c
> @@ -309,7 +309,7 @@ static int task_is_descendant(struct task_struct *parent,
>   * @tracer: the task_struct of the process attempting ptrace
>   * @tracee: the task_struct of the process to be ptraced
>   *
> - * Returns 1 if tracer has is ptracer exception ancestor for tracee.
> + * Returns 1 if tracer has a ptracer exception ancestor for tracee.
>   */
>  static int ptracer_exception_found(struct task_struct *tracer,
>                                    struct task_struct *tracee)
> @@ -320,6 +320,17 @@ static int ptracer_exception_found(struct task_struct *tracer,
>         bool found = false;
>
>         rcu_read_lock();
> +
> +       /* If there's already an active tracing relationship, then make an

I'll adjust the comment style here and add it to my tree for -next.

> +        * exception for the sake of other accesses, like process_vm_rw.
> +        */
> +       parent = ptrace_parent(tracee);
> +       if (parent != NULL && same_thread_group(parent, tracer)) {
> +               rc = 1;
> +               goto unlock;
> +       }
> +
> +       /* Look for a PR_SET_PTRACER relationship. */
>         if (!thread_group_leader(tracee))
>                 tracee = rcu_dereference(tracee->group_leader);
>         list_for_each_entry_rcu(relation, &ptracer_relations, node) {
> @@ -334,6 +345,8 @@ static int ptracer_exception_found(struct task_struct *tracer,
>
>         if (found && (parent == NULL || task_is_descendant(parent, tracer)))
>                 rc = 1;
> +
> +unlock:
>         rcu_read_unlock();
>
>         return rc;
> --
> 2.9.3
>

Thanks!

-Kees

-- 
Kees Cook
Nexus Security