Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030563AbcJ0V1G (ORCPT ); Thu, 27 Oct 2016 17:27:06 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:37738 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964938AbcJ0V1E (ORCPT ); Thu, 27 Oct 2016 17:27:04 -0400 MIME-Version: 1.0 In-Reply-To: <87d1ilrdmt.fsf_-_@xmission.com> References: <20161024105959.GQ1847@uranus.lan> <8760oh8tbp.fsf@xmission.com> <20161024202925.GS1847@uranus.lan> <8760oh737b.fsf@xmission.com> <20161025090213.GX1847@uranus.lan> <87d1ilrdmt.fsf_-_@xmission.com> From: Kees Cook Date: Thu, 27 Oct 2016 14:27:01 -0700 X-Google-Sender-Auth: wXgmv_izBCrWyJ6yzPHwupH6vqg Message-ID: Subject: Re: [REVIEW][PATCH v2] mm: Add a user_ns owner to mm_struct and fix ptrace permission checks To: "Eric W. Biederman" Cc: Cyrill Gorcunov , Andrey Vagin , LKML , Pavel Emelyanov , Linux Containers , Jann Horn Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1708 Lines: 41 On Thu, Oct 27, 2016 at 8:54 AM, Eric W. Biederman wrote: > > During exec dumpable is cleared if the file that is being executed is > not readable by the user executing the file. A bug in > ptrace_may_access allows reading the file if the executable happens to > enter into a subordinate user namespace (aka clone(CLONE_NEWUSER), > unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER). > > This problem is fixed with only necessary userspace breakage by adding > a user namespace owner to mm_struct, captured at the time of exec, so > it is clear in which user namespace CAP_SYS_PTRACE must be present in > to be able to safely give read permission to the executable. > > The function ptrace_may_access is modified to verify that the ptracer > has CAP_SYS_ADMIN in task->mm->user_ns instead of task->cred->user_ns. > This ensures that if the task changes it's cred into a subordinate > user namespace it does not become ptraceable. > > The function ptrace_attach is modified to only set PT_PTRACE_CAP when > CAP_SYS_PTRACE is held over task->mm->user_ns. The intent of > PT_PTRACE_CAP is to be a flag to note that whatever permission changes > the task might go through the tracer has sufficient permissions for > it not to be an issue. task->cred->user_ns is always the same > as or descendent of mm->user_ns. Which guarantees that having > CAP_SYS_PTRACE over mm->user_ns is the worst case for the tasks > credentials. > > Cc: stable@vger.kernel.org > Fixes: 8409cca70561 ("userns: allow ptrace from non-init user namespaces") > Signed-off-by: "Eric W. Biederman" Thanks! Acked-by: Kees Cook -Kees -- Kees Cook Nexus Security