lkml.org 
[lkml]   [2017]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC][PATCH] exec: Use init rlimits for setuid exec
On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook <keescook@chromium.org> wrote:
>>
>> (a) minimal: just use our existing default stack (and stack _only_)
>> limit value for suid binaries that actually get extra permissions: {
>> _STK_LIM, RLIM_INFINITY }.
>
> This would look a lot like the existing patch; it'd just not copy the
> init process rlimits.

Can't we just do the final rlimit setting so late in execve that we
don't need that whole "saved_rlimit" thing?

If the issue is the "people can use argv/envp to already fill the
stack", then I'd actually be happier with just limiting that.

We already claim that our ARG_MAX is just 128kB (old legacy). And I
was really happy when we changed our execve() to not have that nasty
array of pages, and we could expand on the array sizes. But we could
*easily* just say "limit execve arrays to 8MB", because while our code
can handle more, you do have latency issues and just memory use issues
too.

So right now we already limit the stack size artificially to 1/4 the
stack rlimit (see get_arg_page()), and we could easily just further
cap it at 8M total - right now people obviously actually run in
practice with much less (ie for me that argument size is capped at a
quarter of that 8MB default rlimit).

I have heard of people who want a big stack due to crazy recursion or
due to just doing otherwise insane things. But needing more than 8MB
of arg/envp? Not happening.

So I think we could easily do that stack rlimit thing at the very last
minute, and not have to worry about restoring anything.

Linus

\
 
 \ /
  Last update: 2017-07-06 19:52    [W:0.073 / U:0.400 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site