On Fri, Jul 7, 2017 at 1:04 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jul 7, 2017 at 12:56 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> As discussed with Linus and Andy, we need to reset the stack rlimit >> before we do memory layouts when execing a privilege-gaining (e.g. >> setuid) program. This moves security_bprm_secureexec() earlier (with >> required changes), and then lowers the stack limit when appropriate. > > Looks sane to me, and that first patch looks like a nice cleanup > regardless - the old semantics were insane. > > But yes, we should have more people look at this, particular have the > security module people look at that first patch to make sure it is the > right thing to do for their policies, and make sure that everybody's > bprm_secureexec() function actually looks at the creds in the brmp, > not "current" (well, maybe they compare the two, which makes tons of > sense, and which the old placement didn't sanely support). > > It looks like Kees went through the security modules, but having the > people involved double-check is a good good idea. Updated tree here, I'll send the series in email on Monday: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/setuid-rlimits/secureexec This should fix the missed bprm->cred->security and breaks out each step into logical pieces in case we need to sanely bisect. -Kees -- Kees Cook Pixel Security
