linux-kernel - Re: [PATCH] exec: Weaken dumpability for 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]

Date:   Wed, 3 Jan 2018 11:41:15 -0600
From:   "Serge E. Hallyn" <serge@...lyn.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Tom Horsley <horsley1953@...il.com>,
        Laura Abbott <labbott@...hat.com>,
        David Howells <dhowells@...hat.com>,
        James Morris <james.l.morris@...cle.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] exec: Weaken dumpability for secureexec

Quoting Kees Cook (keescook@...omium.org):
> On Tue, Jan 2, 2018 at 11:06 PM, Serge E. Hallyn <serge@...lyn.com> wrote:
> > On Tue, Jan 02, 2018 at 03:21:33PM -0800, Kees Cook wrote:
> >> This is a logical revert of:
> >>
> >>     commit e37fdb785a5f ("exec: Use secureexec for setting dumpability")
> >>
> >> This weakens dumpability back to checking only for uid/gid changes in
> >> current (which is useless), but userspace depends on dumpability not
> >> being tied to secureexec.
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1528633
> >>
> >> Reported-by: Tom Horsley <horsley1953@...il.com>
> >> Fixes: e37fdb785a5f ("exec: Use secureexec for setting dumpability")
> >> Cc: stable@...r.kernel.org
> >> Signed-off-by: Kees Cook <keescook@...omium.org>
> >> ---
> >>  fs/exec.c | 9 +++++++--
> >>  1 file changed, 7 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/fs/exec.c b/fs/exec.c
> >> index 5688b5e1b937..7eb8d21bcab9 100644
> >> --- a/fs/exec.c
> >> +++ b/fs/exec.c
> >> @@ -1349,9 +1349,14 @@ void setup_new_exec(struct linux_binprm * bprm)
> >>
> >>       current->sas_ss_sp = current->sas_ss_size = 0;
> >>
> >> -     /* Figure out dumpability. */
> >> +     /*
> >> +      * Figure out dumpability. Note that this checking only of current
> >> +      * is wrong, but userspace depends on it. This should be testing
> >> +      * bprm->secureexec instead.
> >> +      */
> >>       if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP ||
> >> -         bprm->secureexec)
> >> +         !(uid_eq(current_euid(), current_uid()) &&
> >> +           gid_eq(current_egid(), current_gid())))
> >
> > So what about the pdeath_signal?  Is that going to be another subtle
> > time-bomb?
> 
> pdeath_signal used another wrong method to set itself, but it was
> better than dumpable. I'd rather we leave it as-is, since I'd like to
> have everything controlled by secureexec.

Yes, but if there is some weird userspace out there that depends on
pdeath_signal handling in the same corner case, then we'll break that
just like we did, except it'll be even harder to track down, because
debugging a wrong pdeath_signal will be even more subtle, and it'll
fail only when it's supposed to be exiting...

> The more interesting thing here is that secureexec is set for a
> process that ISN'T actually setuid. (ptrace of a setuid process). I

yeah i'd like to find some time to track that down too.

> think tha'ts the real bug, but not something I'm going to be able to
> fix quickly. So, for now, I want to revert this, then try to fix the
> weird case, and see if that breaks anyone, then fix this back to
> secureexec.

That sounds good, I'm only saying that the core bug is the wrong setting
of secureexec, and you've switched both setting of pdeath and
dumpability to using secureexec, so it stands to reason that setting of
pdeath is still wrong in these cases.

-serge