Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932097Ab3JIR1q (ORCPT ); Wed, 9 Oct 2013 13:27:46 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:39050 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756883Ab3JIR1n (ORCPT ); Wed, 9 Oct 2013 13:27:43 -0400 MIME-Version: 1.0 In-Reply-To: <20131009105402.GA4810@dztty> References: <20131004182353.GA2600@dztty> <20131004191113.GA3916@dztty> <20131004192712.GA4334@dztty> <20131004194142.GA4524@dztty> <20131005132337.GA4095@dztty> <20131009105402.GA4810@dztty> From: Andy Lutomirski Date: Wed, 9 Oct 2013 18:27:22 +0100 Message-ID: Subject: Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task To: Djalal Harouni Cc: "Eric W. Biederman" , Kees Cook , Al Viro , Andrew Morton , Linus Torvalds , Ingo Molnar , "Serge E. Hallyn" , Cyrill Gorcunov , David Rientjes , LKML , Linux FS Devel , "kernel-hardening@lists.openwall.com" , Djalal Harouni Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2401 Lines: 66 On Wed, Oct 9, 2013 at 11:54 AM, Djalal Harouni wrote: > On Mon, Oct 07, 2013 at 02:41:33PM -0700, Andy Lutomirski wrote: >> On Sat, Oct 5, 2013 at 6:23 AM, Djalal Harouni wrote: >> > On Fri, Oct 04, 2013 at 03:17:08PM -0700, Andy Lutomirski wrote: >> >> >> >> Exactly. Hence the NAK. >> > But Having two LSM Hooks there is really not practical! >> >> It'd doable *if* it turns out that it's the right solution. >> >> But revoke seems much more likely to be simple, comprehensible, and >> obviously correct to me. > Yes Andy, I agree, revoke is much better! > > But it will not handle or fix all the situations, as I've said what if > revoke is not invloved here? there is no an execve from the target task! > > > Remember: > /proc/*/{stat,maps} and perhaps others have 0444 and don't have ptrace > checks during ->open() to not break some userspace... especially > /proc/*/stat file For /proc/*/stat: check permissions when opening. If the opener passes the ptrace check, set a flag in file->private_data indicating that this struct file has permission. For /proc/*/maps: either fail the open if the check fails or set a flag that causes the resulting struct file to be useless. > > > So you will have an fd on these privileged files! > > Current will execve a privileged process, and pass ptrace_may_access() > checks during ->read()... > > Here revoke is not involved at all! so it will not fix these files and > they will continue to be vulnerable. > > IMO to fix them, we must have the correct ptrace_may_access() check and > this involves: current doing an execve + current's cred > > > > BTW, Andy we already return 0 (end of file) for /proc/*/mem > ->read() > ->mem_read() > ->mem_rw() > if (!atomic_inc_not_zero(&mm->mm_users)) > return 0 > > So can this be considered some sort of simple revoke? > Apparently not. I haven't looked at the code, but I just tried it. The fd from /proc//maps survives an exec of the process it's pointing at. That means that either the mm changing has no effect on the struct file or that an unshared mm survives exec. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/