Messages in this thread | | | From | Kees Cook <> | Date | Thu, 6 Jul 2017 22:45:07 -0700 | Subject | Re: [RFC][PATCH] exec: Use init rlimits for setuid exec |
| |
On Thu, Jul 6, 2017 at 10:36 PM, Andy Lutomirski <luto@kernel.org> wrote: > On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook <keescook@chromium.org> wrote: >> On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook <keescook@chromium.org> wrote: >>> On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski <luto@kernel.org> wrote: >>>> How about a much simpler solution: don't read rlimit at all in >>>> copy_strings(), let alone try to enforce it. Instead, just before the >>>> point of no return, check how much stack space is already used and, if >>>> it's more than an appropriate threshold (e.g. 1/4 of the rlimit), >>>> abort. Sure, this adds overhead if we're going to abort, but does >>>> that really matter? >>> >>> We should avoid using up tons of memory and then failing. Better to >>> cap it as we use it. Plumbing a sane value into this shouldn't be hard >>> at all. Just making this a hardcoded 2MB seems sane (1/4 of 8MB). > > Aren't there real use cases that use many megs of arguments?
They'd be relatively new since the args were pretty limited before. I'd be curious to see them.
> We could probably get away with saying max(rlimit(RLIMIT_STACK), 2MB) > as long as we make sure later on that we don't screw up if we've > overallocated?
min, not max, but yeah. Here's part of what I have for get_arg_page():
rlim = current->signal->rlim; - if (size > READ_ONCE(rlim[RLIMIT_STACK].rlim_cur) / 4) + arg_stack = READ_ONCE(rlim[RLIMIT_STACK].rlim_cur); + arg_stack = min_t(unsigned long, arg_stack, _STK_LIM) / 4; + if (size > arg_stack) goto fail;
>>> IIUC, this is a big deal on 32-bit. Unlimited stack triggers top-down >>> mmap instead of bottom-up. I mean, I'd be delighted to get rid of >>> this, but I thought it was relied on by userspace. >> >> I always say this backwards. :P Default is top-down (allocate at high >> addresses and work down toward low). With unlimited stack, allocations >> start at low addresses and work up. Here's the results (shown with >> randomize_va_space sysctl set to 0): > > Uhh, crikey! Where's the code that does that?
That was the call path I quoted earlier:
> The stack rlimit defines the mmap layout too: > > do_execveat_common() -> > exec_binprm() -> > search_binary_handler() -> > fmt->load_binary (load_elf_binary()) -> > setup_new_exec() -> > arch_pick_mmap_layout() -> > mmap_is_legacy() -> > rlimit(RLIMIT_STACK) == RLIM_INFINITY
i.e. arch_pick_mmap_layout().
-Kees
-- Kees Cook Pixel Security
| |