linux-kernel - Re: [PATCH v2 8/8] exec: Use sane stack rlimit under secureexec

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]

Message-ID: <1499695718.2707.120.camel@decadent.org.uk>
Date:   Mon, 10 Jul 2017 15:08:38 +0100
From:   Ben Hutchings <ben@...adent.org.uk>
To:     Kees Cook <keescook@...omium.org>,
        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>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Michal Hocko <mhocko@...nel.org>,
        Hugh Dickins <hughd@...gle.com>,
        Oleg Nesterov <oleg@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...hat.com>,
        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@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov
Subject: Re: [PATCH v2 8/8] exec: Use sane stack rlimit under secureexec

On Mon, 2017-07-10 at 00:57 -0700, Kees Cook wrote:
> For a secureexec, before memory layout selection has happened, reset the
> stack rlimit to something sane to avoid the caller having control over
> the resulting layouts.
> 
> $ ulimit -s
> 8192
> $ ulimit -s unlimited
> $ /bin/sh -c 'ulimit -s'
> unlimited
> $ sudo /bin/sh -c 'ulimit -s'
> 8192
> 
> Signed-off-by: Kees Cook <keescook@...omium.org>
> ---
>  fs/exec.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/fs/exec.c b/fs/exec.c
> index e0186db02f90..1e3463854a16 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1343,6 +1343,16 @@ void setup_new_exec(struct linux_binprm * bprm)
>  
>  		/* Make sure parent cannot signal privileged process. */
>  		current->pdeath_signal = 0;
> +
> +		/*
> +		 * For secureexec, reset the stack limit to sane default to
> +		 * avoid bad behavior from the prior rlimits. This has to
> +		 * happen before arch_pick_mmap_layout(), which examines
> +		 * RLIMIT_STACK, but after the point of no return to avoid
> +		 * needing to clean up the change on failure.
> +		 */
> +		if (current->signal->rlim[RLIMIT_STACK].rlim_cur > _STK_LIM)
> +			current->signal->rlim[RLIMIT_STACK].rlim_cur = _STK_LIM;

As setup_new_exec() is called before install_exec_creds(), I think this
leaves a window where the real user can change the limit again with
prlimit().

Ben.

>  	}
>  
>  	arch_pick_mmap_layout(current->mm);
-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)