Re: [gentoo-hardened] systemd-229 segfault triggers bruteforce prevention

[Tóth Attila]

2016.Június 2.(Cs) 21:39 időpontban "Tóth Attila" ezt írta:
> 2016.Június 2.(Cs) 02:31 időpontban Max R.D. Parmer ezt írta:
>> Not necessarily the ideal solution, but have you tried twiddling with
>> the stack size in limits.conf?
>
> I checked an the system-wide defaults apply to systemd, which is: 8M soft
> limit and _unlimited_ hard limit for stack size. So after exceeding soft
> limit systemd segfaults and tries to dump core.
>
> cat /proc/1/limits
> Limit                     Soft Limit           Hard Limit           Units
> Max stack size            8388608              unlimited            bytes
>
> I expect any process to handle a situation of trying to exceed soft limit
> with unlimited hard limit in another way than segfaulting and attempting
> to dump core...

Increasing the limit doesn't fix the issue - I'm not surprised about that.

For those who are not familiar: systemd doesn't respect limits.conf. In
system.conf the default values can be configured and per unit limits can
be specified. To my surprise, systemd doesn't seem to pay attention to
it's own configuration file. In order to provide increased stack limit for
init, I also modified the kernel defaults. With no success.

>> If I read this right, grsec limits the size of the stack, which causes
>> the process to segfault.
>
> I think grsec does not enforce any stack limits here, it just reports the
> issue and makes it more visible.

I did a bisect and it turns out a this commit is responsible for the
symptoms:
https://github.com/systemd/systemd/commit/d054f0a4d451120c26494263fc4dc175bfd405b1
tree-wide: use xsprintf() where applicable

I try to contact the developer. Whether he has an idea on what is
happening here.

BR: Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, [phone]