Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757782AbcJXVcM (ORCPT ); Mon, 24 Oct 2016 17:32:12 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:38372 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756454AbcJXVcI (ORCPT ); Mon, 24 Oct 2016 17:32:08 -0400 MIME-Version: 1.0 In-Reply-To: <20161024202925.GS1847@uranus.lan> References: <20161024105959.GQ1847@uranus.lan> <8760oh8tbp.fsf@xmission.com> <20161024202925.GS1847@uranus.lan> From: Kees Cook Date: Mon, 24 Oct 2016 14:32:06 -0700 X-Google-Sender-Auth: Qrbe6LehTBShMNtYVFheDrTsAfg Message-ID: Subject: Re: [ISSUE] mm: Add a user_ns owner to mm_struct and fix ptrace_may_access To: Cyrill Gorcunov Cc: "Eric W. Biederman" , Andrey Vagin , LKML , Pavel Emelyanov , Linux Containers 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: 1236 Lines: 29 On Mon, Oct 24, 2016 at 1:29 PM, Cyrill Gorcunov wrote: > On Mon, Oct 24, 2016 at 02:01:30PM -0500, Eric W. Biederman wrote: >> So I am probably going to tweak the !mm case so that instead of failing >> we perform the old capable check in that case. That seems the mot >> certain way to avoid regressions. With that said, why is exit_code >> behind a ptrace_may_access permission check? > > Yes, this would be great! And as to @exit_code I think better ask > Kees, CC'ed. My concern was that this was an exposure in the sense that it is internal program state that isn't visible through other means (without being the parent, for example). Under the ptrace check, it has an equivalency that seemed correct at the time. As already covered, I'd agree: it looks like ce99dd5fd5f6 accidentally added a dependency on task->mm where it didn't before. That section of logic was entirely around dumpability, not an mm existing. It should be "EPERM if mm and dumpable != SUID_DUMP_USER". That said, I'd also agree that ptrace against no mm is crazy (though I suppose that should return EINVAL or ESRCH or something), so perhaps a better access control on @exit_code is needed here. -Kees -- Kees Cook Nexus Security