Date: Fri, 4 Oct 2013 15:59:51 -0700 From: Andy Lutomirski <luto@...capital.net> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: Djalal Harouni <tixxdz@...ndz.org>, Kees Cook <keescook@...omium.org>, Al Viro <viro@...iv.linux.org.uk>, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Ingo Molnar <mingo@...nel.org>, "Serge E. Hallyn" <serge.hallyn@...ntu.com>, Cyrill Gorcunov <gorcunov@...nvz.org>, David Rientjes <rientjes@...gle.com>, LKML <linux-kernel@...r.kernel.org>, Linux FS Devel <linux-fsdevel@...r.kernel.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Djalal Harouni <tixxdz@...il.com> Subject: Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task On Fri, Oct 4, 2013 at 3:55 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote: > Andy Lutomirski <luto@...capital.net> writes: > >> On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni <tixxdz@...ndz.org> 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 <tixxdz@...ndz.org> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.