Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754418Ab3JMKSl (ORCPT ); Sun, 13 Oct 2013 06:18:41 -0400 Received: from numidia.opendz.org ([98.142.220.152]:51459 "EHLO numidia.opendz.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754083Ab3JMKSj (ORCPT ); Sun, 13 Oct 2013 06:18:39 -0400 Date: Sun, 13 Oct 2013 11:18:34 +0100 From: Djalal Harouni To: Andy Lutomirski 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 Subject: Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task Message-ID: <20131013101834.GA4404@dztty> References: <20131004191113.GA3916@dztty> <20131004192712.GA4334@dztty> <20131004194142.GA4524@dztty> <20131005132337.GA4095@dztty> <20131009105402.GA4810@dztty> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3151 Lines: 84 On Wed, Oct 09, 2013 at 06:27:22PM +0100, Andy Lutomirski wrote: > 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. That will fix it, but it will need some extra work since file->private_data is already used to store seq_file structs! > For /proc/*/maps: either fail the open if the check fails or set a > flag that causes the resulting struct file to be useless. Not sure about this, we need to inspect glibc > > > > > > 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. yes the old mm (during ->open()) will survive but not vma, ->read() will return zero In the mean time, to close some of these vulnerabilities, I'll submit another patch to prevent open() arbitrary /proc/*/{stack,syscall} 1) Make them 0400 2) Add the ptrace_may_access() during ->open() for ptrace capabilities and LSM checks It would be nice to get your Acked-by Andy! -- Djalal Harouni http://opendz.org -- 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/