> (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 }.
Even that is dangerous because a setuid binary can be transitioning
between two users (none privileged) yet be subject to an rl
On Mon, 2017-07-10 at 20:16 +0200, Michal Hocko wrote:
> OK, I misread the code. 32b applications on 64b systems do top down
> by
> default and only if they override this by ADDR_COMPAT_LAYOUT
> personality. For some reason I thought that 32b userspace goes a
> different path and makes sure that t
On Mon 10-07-17 18:27:51, Michal Hocko wrote:
> On Mon 10-07-17 09:12:11, Kees Cook wrote:
[...]
> > >> do_execveat_common() ->
> > >> exec_binprm() ->
> > >> search_binary_handler() ->
> > >> fmt->load_binary (load_elf_binary()) ->
> > >> setup_new_exec() ->
> > >> arch_pick_mmap_layout() ->
> > >
On Mon, Jul 10, 2017 at 09:18:09AM -0700, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 9:12 AM, Kees Cook wrote:
> >
> > Sounds good to me, but won't large-memory users in 32-bit get annoyed?
>
> We'll see.
>
> I suspect that all large-memory users have long since upgraded to
> x86-64 (rule o
On Mon 10-07-17 09:12:11, Kees Cook wrote:
> On Mon, Jul 10, 2017 at 1:44 AM, Michal Hocko wrote:
> > On Thu 06-07-17 12:12:55, Kees Cook wrote:
> >> On Thu, Jul 6, 2017 at 10:52 AM, Linus Torvalds
> >> wrote:
> >> > On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook wrote:
> >> >>>
> >> >>> (a) minima
On Mon, Jul 10, 2017 at 9:12 AM, Kees Cook wrote:
>
> Sounds good to me, but won't large-memory users in 32-bit get annoyed?
We'll see.
I suspect that all large-memory users have long since upgraded to
x86-64 (rule of thumb: if you are upgrading kernels today, you
probably upgraded hardware ten
On Mon, Jul 10, 2017 at 1:44 AM, Michal Hocko wrote:
> On Thu 06-07-17 12:12:55, Kees Cook wrote:
>> On Thu, Jul 6, 2017 at 10:52 AM, Linus Torvalds
>> wrote:
>> > On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook wrote:
>> >>>
>> >>> (a) minimal: just use our existing default stack (and stack _only_)
On Thu 06-07-17 12:12:55, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 10:52 AM, Linus Torvalds
> wrote:
> > On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook wrote:
> >>>
> >>> (a) minimal: just use our existing default stack (and stack _only_)
> >>> limit value for suid binaries that actually get extra
On Fri, Jul 7, 2017 at 9:06 AM, Linus Torvalds
wrote:
> On Thu, Jul 6, 2017 at 11:10 PM, Kees Cook wrote:
>> On Thu, Jul 6, 2017 at 11:02 PM, Linus Torvalds
>> wrote:
>>> So 2+MB is still definitely something people can do (and probably *do* do).
>>
>> With the default 8MB stack, most people are
On Fri, Jul 7, 2017 at 9:22 AM, Linus Torvalds
wrote:
> On Thu, Jul 6, 2017 at 11:40 PM, Kees Cook wrote:
> So I definitely like this approach, as long as we clarify that crazy
> security_bprm_secureexec() model. That code really is insane.
Yeah, it really seems like security_bprm_secureexec() s
On Thu, Jul 6, 2017 at 11:40 PM, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 10:49 PM, Kees Cook wrote:
>
> At Andy's suggestion I'm using security_bprm_secureexec() to test for
> setuid-ness. However, this seems to expect the credentials to have
> already been installed.
That function actually ta
On Thu, Jul 6, 2017 at 11:10 PM, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 11:02 PM, Linus Torvalds
> wrote:
>> So 2+MB is still definitely something people can do (and probably *do* do).
>
> With the default 8MB stack, most people are already limited to 2MB
> here. I guess the question is, do pe
On Thu, Jul 6, 2017 at 10:45 PM, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 10:36 PM, Andy Lutomirski wrote:
>> 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
On Thu, Jul 6, 2017 at 10:49 PM, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 10:39 PM, Linus Torvalds
>> And I think the credentials switch (which is the point of no return
>> anyway) happens before we start mmap'ing the executable etc. We used
>> to have some odd code there and do it in the complet
On Thu, Jul 6, 2017 at 11:02 PM, Linus Torvalds
wrote:
> So 2+MB is still definitely something people can do (and probably *do* do).
With the default 8MB stack, most people are already limited to 2MB
here. I guess the question is, do people raise their stack rlimit to
gain more arguments? Should
On Thu, Jul 6, 2017 at 10:45 PM, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 10:36 PM, Andy Lutomirski wrote:
>>
>> 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.
"megs" yes. "many m
On Thu, Jul 6, 2017 at 10:39 PM, Linus Torvalds
wrote:
> On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote:
>>
>> 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. H
On Thu, Jul 6, 2017 at 10:36 PM, Andy Lutomirski wrote:
> On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote:
>> On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote:
>>> On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote:
How about a much simpler solution: don't read rlimit at all in
co
On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote:
>
> 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
On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote:
>> On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote:
>>> How about a much simpler solution: don't read rlimit at all in
>>> copy_strings(), let alone try to enforce it. Instead, just befor
On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski 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
On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski 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
On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote:
>
> How about a much simpler solution: don't read rlimit at all in
> copy_strings(), let alone try to enforce it.
People have historically relied on E2BIG and then splitting things
into multiple chunks (ie do the whole 'xargs' thing).
But I
On Thu, Jul 6, 2017 at 12:12 PM, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 10:52 AM, Linus Torvalds
> wrote:
>> On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook wrote:
(a) minimal: just use our existing default stack (and stack _only_)
limit value for suid binaries that actually get ex
On Thu, Jul 6, 2017 at 10:52 AM, Linus Torvalds
wrote:
> On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook 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 }.
>>
>> Thi
On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook 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 t
On Thu, Jul 6, 2017 at 9:34 AM, Linus Torvalds
wrote:
> On Wed, Jul 5, 2017 at 9:32 PM, Kees Cook wrote:
>> In an attempt to provide sensible rlimit defaults for setuid execs, this
>> inherits the namespace's init rlimits:
>
> Yeah, so I have to admit to hating this patch.
Yup! Totally fine. I j
On Thu, Jul 6, 2017 at 9:34 AM, Linus Torvalds
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 }.
>
> (c) perhaps encourage people to annotate their suid binaries with
On Wed, Jul 5, 2017 at 9:32 PM, Kees Cook wrote:
> In an attempt to provide sensible rlimit defaults for setuid execs, this
> inherits the namespace's init rlimits:
Yeah, so I have to admit to hating this patch.
As already mentioned by others, it's not only not clear that we want
to do this on e
On Thu, Jul 6, 2017 at 5:38 AM, Eric W. Biederman wrote:
> Kees Cook writes:
>
>> In an attempt to provide sensible rlimit defaults for setuid execs, this
>> inherits the namespace's init rlimits:
>>
>> $ ulimit -s
>> 8192
>> $ ulimit -s unlimited
>> $ /bin/sh -c 'ulimit -s'
>> unlimited
>> $ sud
On Thu, Jul 6, 2017 at 5:45 AM, Eric W. Biederman wrote:
>
> How this is handled elsewhere in the code is to put the new values in
> bprm. Putting new rlimits in bprm and changing them in flush_old_exec
> or or setup_new_exec seems very sensible. It also allows for them to be
> accessed before de
Andy Lutomirski writes:
> On Wed, Jul 5, 2017 at 9:32 PM, Kees Cook wrote:
>> In an attempt to provide sensible rlimit defaults for setuid execs, this
>> inherits the namespace's init rlimits:
>>
>> $ ulimit -s
>> 8192
>> $ ulimit -s unlimited
>> $ /bin/sh -c 'ulimit -s'
>> unlimited
>> $ sudo /
Kees Cook writes:
> In an attempt to provide sensible rlimit defaults for setuid execs, this
> inherits the namespace's init rlimits:
>
> $ ulimit -s
> 8192
> $ ulimit -s unlimited
> $ /bin/sh -c 'ulimit -s'
> unlimited
> $ sudo /bin/sh -c 'ulimit -s'
> 8192
>
> This is modified from Brad Spengle
On Wed, Jul 05, 2017 at 09:32:35PM -0700, Kees Cook wrote:
> In an attempt to provide sensible rlimit defaults for setuid execs, this
> inherits the namespace's init rlimits:
>
> $ ulimit -s
> 8192
> $ ulimit -s unlimited
> $ /bin/sh -c 'ulimit -s'
> unlimited
> $ sudo /bin/sh -c 'ulimit -s'
> 819
On Wed, Jul 5, 2017 at 9:32 PM, Kees Cook wrote:
> In an attempt to provide sensible rlimit defaults for setuid execs, this
> inherits the namespace's init rlimits:
>
> $ ulimit -s
> 8192
> $ ulimit -s unlimited
> $ /bin/sh -c 'ulimit -s'
> unlimited
> $ sudo /bin/sh -c 'ulimit -s'
> 8192
>
> This
35 matches
Mail list logo
