On Fri, Oct 4, 2013 at 3:55 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > >> On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni <tixxdz@xxxxxxxxxx> 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@xxxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
