Re: [PATCH v2 0/3] posix: Execute file function fixes

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

> Em 19 de fev de 2016, Ãs 17:58, Paul Eggert <eggert@cs.ucla.edu> escreveu:
> 
>> On 02/19/2016 11:14 AM, Adhemerval Zanella wrote:
>> I do not agree it is a regression since it fixes two important issues:
>> exec async-signal-safeness and vfork usage.
> 
> Even if a change makes improvements in some ways, the change can still be a regression in other ways. The proposed change plainly has such regressions.
> 
>> the vector of attack might be limited
> 
> Agreed. Still, the vector is there.

And I am open to suggestions on how to harden the code against attacks, but I do see it as blocker to prevent since current implementations have serious limitations. 

And it is a regression only if you consider dynamic allocation an alternative, which is not the case. 

> 
>> The current '__libc_use_alloca' is a fragile and arbitrary stack control flow and since it does not track total stack usage against runtime imposed limit it does not add anything related to security.
> 
> Certainly __libc_use_alloca is an imperfect mechanism. However, if code touches buffers before going past them, __libc_use_alloca results in reliable stack overflow protection in the common case where sufficiently-large guard pages are at the top of the stack. So it's an exaggeration to say that __libc_use_alloca adds nothing to security.

The problem it is not realible, it adds code complexity in buffer handling, it does track current stack usage, the limit is arbitrary. It is very limited scope implementation of fstack-check.

A better strategy would be set either hard limits on stack usage in design phase or to focus on enable GLIBC to use a better stack protection mechanism (preferable through compiler assistance).