[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGXu5jLTAXdPw7ZQ3B=EupO_+6-4Y4rsJN0xbaFkX2amjdC5tQ@mail.gmail.com>
Date: Fri, 7 Jul 2017 20:59:32 -0700
From: Kees Cook <keescook@...omium.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andy Lutomirski <luto@...nel.org>,
David Howells <dhowells@...hat.com>,
Serge Hallyn <serge@...lyn.com>,
John Johansen <john.johansen@...onical.com>,
Casey Schaufler <casey@...aufler-ca.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Michal Hocko <mhocko@...nel.org>,
Ben Hutchings <ben@...adent.org.uk>,
Hugh Dickins <hughd@...gle.com>,
Oleg Nesterov <oleg@...hat.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Rik van Riel <riel@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
James Morris <james.l.morris@...cle.com>,
Greg Ungerer <gerg@...ux-m68k.org>,
Ingo Molnar <mingo@...nel.org>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Stephen Smalley <sds@...ho.nsa.gov>,
Paul Moore <paul@...l-moore.com>,
Vivek Goyal <vgoyal@...hat.com>,
Mickaël Salaün <mic@...ikod.net>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 0/2] exec: Use sane stack rlimit for setuid exec
On Fri, Jul 7, 2017 at 1:04 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Jul 7, 2017 at 12:56 PM, Kees Cook <keescook@...omium.org> 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
Powered by blists - more mailing lists