From patchwork Thu Dec 1 01:24:01 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josh Stone X-Patchwork-Id: 9455257 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 774DB60585 for ; Thu, 1 Dec 2016 01:24:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6AD262849A for ; Thu, 1 Dec 2016 01:24:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5F1B7283E4; Thu, 1 Dec 2016 01:24:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 679B82849F for ; Thu, 1 Dec 2016 01:24:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753585AbcLABYY (ORCPT ); Wed, 30 Nov 2016 20:24:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55872 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752607AbcLABYX (ORCPT ); Wed, 30 Nov 2016 20:24:23 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9C01F8124D; Thu, 1 Dec 2016 01:24:22 +0000 (UTC) Received: from moya.redhat.com (ovpn-116-143.phx2.redhat.com [10.3.116.143]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB11OLxh021045; Wed, 30 Nov 2016 20:24:21 -0500 From: Josh Stone To: linux-kernel@vger.kernel.org Cc: Josh Stone , Kees Cook , James Morris , "Serge E. Hallyn" , linux-security-module@vger.kernel.org Subject: [PATCH] Yama: allow access for the current ptrace parent Date: Wed, 30 Nov 2016 17:24:01 -0800 Message-Id: <20161201012401.17367-1-jistone@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 01 Dec 2016 01:24:22 +0000 (UTC) Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: X-Virus-Scanned: ClamAV using ClamSMTP 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. Signed-off-by: Josh Stone Cc: Kees Cook Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-security-module@vger.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 + * 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;