linux-kernel - Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Jul 2017 23:40:30 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Michal Hocko <mhocko@...nel.org>,
        Ben Hutchings <ben@...adent.org.uk>, Willy Tarreau <w@....eu>,
        Hugh Dickins <hughd@...gle.com>,
        Oleg Nesterov <oleg@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...hat.com>,
        Larry Woodman <lwoodman@...hat.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Tony Luck <tony.luck@...el.com>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Helge Diller <deller@....de>,
        James Hogan <james.hogan@...tec.com>,
        Laura Abbott <labbott@...hat.com>, Greg KH <greg@...ah.com>,
        "security@...nel.org" <security@...nel.org>,
        Qualys Security Advisory <qsa@...lys.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ximin Luo <infinity0@...ian.org>
Subject: Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:49 PM, Kees Cook <keescook@...omium.org> wrote:
> On Thu, Jul 6, 2017 at 10:39 PM, Linus Torvalds
>> And I think the credentials switch (which is the point of no return
>> anyway) happens before we start mmap'ing the executable etc. We used
>> to have some odd code there and do it in the completely wrong order
>> (checking that the binary was executable for the *old* user, which
>> makes no sense, iirc)
>
> Yeah, it all happens in setup_new_exec(). The first thing is layout
> selection, then switching credentials. It could be made to take a hint
> from GNU_STACK (which was parsed before setup_new_exec() is called),
> check security_bprm_secureexec() and then make the rlimit changes, all
> before the layout selection.

At Andy's suggestion I'm using security_bprm_secureexec() to test for
setuid-ness. However, this seems to expect the credentials to have
already been installed. And yet ... the following patch still works
correctly when I call it "early". I'm going to look again in the
morning.

diff --git a/fs/exec.c b/fs/exec.c
index b60804216b59..a4d2433a44ec 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1334,9 +1334,20 @@ EXPORT_SYMBOL(would_dump);

 void setup_new_exec(struct linux_binprm * bprm)
 {
+       /* This is the point of no return */
+
+       /*
+        * If this is a setuid execution, reset the stack limit to
+        * a sane default to avoid bad behavior from the prior rlimits.
+        */
+       if (security_bprm_secureexec(bprm)) {
+               struct rlimit default_stack = { _STK_LIM, RLIM_INFINITY };
+
+               current->signal->rlim[RLIMIT_STACK] = default_stack;
+       }
+
        arch_pick_mmap_layout(current->mm);

-       /* This is the point of no return */
        current->sas_ss_sp = current->sas_ss_size = 0;

        if (uid_eq(current_euid(), current_uid()) &&
gid_eq(current_egid(), current_gid()))



-- 
Kees Cook
Pixel Security