Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752971Ab3JDXAQ (ORCPT ); Fri, 4 Oct 2013 19:00:16 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:34337 "EHLO mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752313Ab3JDXAN (ORCPT ); Fri, 4 Oct 2013 19:00:13 -0400 MIME-Version: 1.0 In-Reply-To: <87fvsgy7cn.fsf@xmission.com> References: <20131003201332.GA3500@dztty> <20131004085911.GA2157@dztty> <20131004182353.GA2600@dztty> <20131004191113.GA3916@dztty> <20131004192712.GA4334@dztty> <20131004194142.GA4524@dztty> <87fvsgy7cn.fsf@xmission.com> From: Andy Lutomirski Date: Fri, 4 Oct 2013 15:59:51 -0700 Message-ID: Subject: Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task To: "Eric W. Biederman" 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 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: 3316 Lines: 79 On Fri, Oct 4, 2013 at 3:55 PM, Eric W. Biederman wrote: > 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. If you could ptrace a process before it calls setuid and you can't after it calls setuid, then this is stupid and doesn't matter -- once you've pwned a process, you retain your pwnership at least until exec. So yes, except that it's not just suid exec. It's any exec that any LSM would not do if no_new_privs were set. > > 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. Hmm. So why don't we just do a revoke whenever an exec that changes cred happens? (This will have some false positives, like unsharing userns, I think, but we probably don't care.) > > 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. Can you point us at that infrastructure? My limited grepping skills didn't spot it. I'd really like a solution where there are no read or write implementations in the entire kernel that check permissions. Failing that, just getting it for procfs would be nice. (uid_map, etc will probably need to be revoked on unshare for this to work.) --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/