linux-kernel - Re: [PATCH v3 00/15] 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: <CAGXu5jLrJerqA-e=s=w20yuGENa8RJ1KToccCTwjwb=rT9KdSw@mail.gmail.com>
Date:   Tue, 18 Jul 2017 22:23:49 -0700
From:   Kees Cook <keescook@...omium.org>
To:     "Serge E. Hallyn" <serge@...lyn.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        John Johansen <john.johansen@...onical.com>,
        Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        James Morris <james.l.morris@...cle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 00/15] exec: Use sane stack rlimit under secureexec

On Tue, Jul 18, 2017 at 8:22 PM, Serge E. Hallyn <serge@...lyn.com> wrote:
> On Tue, Jul 18, 2017 at 03:25:21PM -0700, Kees Cook wrote:
>> This series has grown... :P
>>
>> 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. To do this, we need to know the results of the
>> bprm_secureexec hook before memory layouts. As it turns out, this
>> can be made _mostly_ trivial by collapsing bprm_secureexec into
>> bprm_set_creds.
>>
>> The LSMs using bprm_secureexec nearly always save state between
>> bprm_set_creds and bprm_secureexec. In the face of multiple calls to
>> bprm_set_creds (via prepare_binprm() calls from binfmt_script, etc),
>> all LSMs except commoncap only pay attention to the first call, so
>> that aligns well with collapsing bprm_secureexec into bprm_set_creds.
>> The commoncaps, though, needs to check the _last_ bprm_set_creds, so
>> this series just swaps one bprm flag for another (cap_effective is no
>> longer needed to save state between bprm_set_creds and bprm_secureexec,
>> but we do need to keep a separate state, so we add the cap_elevated flag).
>>
>> Once secureexec is available to setup_new_exec() before the memory
>> layout, we can add an rlimit sanity-check for setuid execs. (With no
>> need to clean up since we're past the point of no return.)
>>
>> Along the way, this fixes comments, renames a variable, and consolidates
>> dumpability and pdeath_signal clearing, which includes some commit log
>> archeology to examine the subtle differences between what we had and
>> what we need.
>>
>> I'd appreciate some extra eyes on this to make sure this isn't broken
>> in some special way. Looking at the diffstat, even after all my long
>> comments, this is a net reduction in lines. :)
>>
>> Given this crosses a bunch of areas, I think this is likely best to
>> go via the -mm tree, which is where nearly all of my prior exec work
>> has lived too.
>>
>> Thanks!
>>
>> -Kees
>> ----------------------------------------------------------------
>> Kees Cook (15):
>>       binfmt: Introduce secureexec flag
>>       exec: Rename bprm->cred_prepared to called_set_creds
>>       apparmor: Refactor to remove bprm_secureexec hook
>>       selinux: Refactor to remove bprm_secureexec hook
>>       smack: Refactor to remove bprm_secureexec hook
>>       commoncap: Refactor to remove bprm_secureexec hook
>>       commoncap: Move cap_elevated calculation into bprm_set_creds
>>       LSM: drop bprm_secureexec hook
>>       exec: Correct comments about "point of no return"
>>       exec: Use secureexec for setting dumpability
>>       exec: Use secureexec for clearing pdeath_signal
>>       smack: Remove redundant pdeath_signal clearing
>>       exec: Consolidate dumpability logic
>>       exec: Use sane stack rlimit under secureexec
>>       exec: Consolidate pdeath_signal clearing
>
> Thanks, the set looks good to me,

Thanks!

> Acked-by: Serge Hallyn <serge@...lyn.com>
>
> Have you had a chance to run the ltp caps tests against this?

The LTP caps tests I could find are these:

sudo ./runltp -f syscalls -s cap
sudo ./runltp -f securebits
sudo ./runltp -f cap_bounds
sudo ./runltp -f filecaps

They all run successfully. Was there other stuff from LTP?

And, FWIW, the kernel selftests for capabilities and exec continue to pass too.

-Kees

-- 
Kees Cook
Pixel Security