Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752846Ab3JDWzV (ORCPT ); Fri, 4 Oct 2013 18:55:21 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:39742 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751374Ab3JDWzT (ORCPT ); Fri, 4 Oct 2013 18:55:19 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: Djalal Harouni , 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 References: <20131003201332.GA3500@dztty> <20131004085911.GA2157@dztty> <20131004182353.GA2600@dztty> <20131004191113.GA3916@dztty> <20131004192712.GA4334@dztty> <20131004194142.GA4524@dztty> Date: Fri, 04 Oct 2013 15:55:04 -0700 In-Reply-To: (Andy Lutomirski's message of "Fri, 4 Oct 2013 15:17:08 -0700") Message-ID: <87fvsgy7cn.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+d2xV4wUALn6mqeL4tMj6jjRvvTZlLTgQ= X-SA-Exim-Connect-IP: 98.207.154.105 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 3.4 KHOP_BIG_TO_CC Sent to 10+ recipients instaed of Bcc or a list * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% * [score: 0.1185] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_04 7+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject * 1.0 T_XMDrugObfuBody_08 obfuscated drug references * 0.0 T_TooManySym_03 6+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;Andy Lutomirski X-Spam-Relay-Country: Subject: Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2315 Lines: 58 Andy Lutomirski writes: > On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni wrote: >> On Fri, Oct 04, 2013 at 12:32:09PM -0700, Andy Lutomirski wrote: >>> On Fri, Oct 4, 2013 at 12:27 PM, Djalal Harouni wrote: >>> > So sorry Andy, I don't follow what you are describing. >>> >>> And what parameters are you passing to security_ptrace_access_check? >>> It's supposed to be f_cred, right? Because you want to make sure >>> that, if the opener had some low-privilege label, the target has >>> execed and gotten a more secure label, and the reader has a >>> high-privilege label, that the opener's label is checked against the >>> target's new label. >> The current's cred each time. > > Exactly. Hence the NAK. > >> >> Is there some mechanism to check what you describe? >> > > No. You could try to add one, but getting it to be compatible with > YAMA might be really messy. > > Or you could see if destroying and recreating all the inodes on exec > or some other revoke-like approach would work. This is a revoke like approach, and yes proc has a fully functional revoke infrastructure. Right now that revoke is based on the process going away. The problem challenge is that the process is morphing. The practical question is which runtime checks do we want to perform. If we can say in no uncertain terms that short of a suid exec that no calls (such as setuid) can change the process permissions beyond our ability to access the file, we can detect and exec and use that as a signal. Alternatively we may to look at a processes credentials and in all cases where those change use that as a signal that the file must be reopened. Right now the model that we do a full permission check at every system call because the morphing process may cause problems. If analysis can be done to show that we can use a simpler check than a full permission check that would be grand. The problem is not lack of techinical infrastructure (revoke). The problem is a question of which tests are sufficient. Eric -- 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/