Re: [gentoo-hardened] systemd-229 segfault triggers bruteforce prevention
On Wed, Jun 1, 2016, at 15:49, Tóth Attila wrote: > I've just had an unsuccessful attempt to upgrade to systemd-230-r1. It > segfaults and slows the system down. The symptoms are better compared to > -229, but still significant. > > https://forums.grsecurity.net/viewtopic.php?f=3&t=4485 > > Some relevant log entries: > grsec: denied resource overstep by requesting 8392704 for RLIMIT_STACK > against limit 8388608 for /usr/lib64/systemd/systemd[systemd:2735] > uid/euid:0/0 gid/egid:0/0, parent /usr/lib64/systemd/systemd[systemd:1] > uid/euid:0/0 gid/egid:0/0 > systemd[2735]: segfault at 39f8d01cf00 ip 0368d4caa2e4 sp > 039f8d01cf00 error 6 in libc-2.23.so[368d4c62000+19a000] > grsec: Segmentation fault occurred at 039f8d01cf00 in > /usr/lib64/systemd/systemd[systemd:2735] uid/euid:0/0 gid/egid:0/0, > parent > /usr/lib64/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0 > grsec: bruteforce prevention initiated for the next 30 minutes or until > service restarted, stalling each fork 30 seconds. Please investigate the > crash report for /usr/lib64/systemd/systemd[systemd:2735] uid/euid:0/0 > gid/egid:0/0, parent /usr/lib64/systemd/systemd[systemd:1] uid/euid:0/0 > gid/egid:0/0 > > systemd-coredump[2747]: Process 2735 (systemd) of user 0 dumped core. > >Stack trace of thread > 2735: >#0 0x0368d4caa2e4 > _IO_vfprintf > (libc.so.6) >#1 0x0368d4d5e852 > __vsnprintf_chk > (libc.so.6) >#2 0x0368d4d5e7a4 > __snprintf_chk > (libc.so.6) >#3 0xdf8db344 > n/a (systemd) >#4 0xdf8db9aa > n/a (systemd) >#5 0xdf8da72f > n/a (systemd) >#6 0xdf8db314 > n/a (systemd) >#7 0xdf8db9aa > n/a (systemd) >#8 0xdf8da72f > n/a (systemd) >#9 0xdf8db314 > n/a (systemd) >#10 0xdf8db9aa > n/a (systemd) >#11 0xdf8da72f > n/a (systemd) >#12 0xdf8db314 > n/a (systemd) >#13 0xdf8db9aa > n/a (systemd) >#14 0xdf8da72f > n/a (systemd) >#15 0xdf8db314 > n/a (systemd) >#16 0xdf8db9aa > n/a (systemd) >#17 0xdf8da72f > n/a (systemd) >#18 0xdf8db314 > n/a (systemd) >#19 0xdf8db9aa > n/a (systemd) >#20 0xdf8da72f > n/a (systemd) >#21 0xdf8db314 > n/a (systemd) >#22 0xdf8db9aa > n/a (systemd) >#23 0xdf8da72f > n/a (systemd) >#24 0xdf8db314 > n/a (systemd) >#25 0xdf8db9aa > n/a (systemd) >#26 0xdf8da72f > n/a (systemd) >#27 0xdf8db314 > n/a (systemd) >#28 0xdf8db9aa > n/a (systemd) >#29 0xdf8da72f > n/a (systemd) >#30 0xdf8db314 > n/a (systemd) >#31 0xdf8db9aa > n/a (systemd) >#32 0xdf8da72f > n/a (systemd) >#33 0xdf8db314 > n/a (systemd) >#34 0xdf8db9aa > n/a (systemd) >#35 0xdf8da72f > n/a (systemd) >#36 0xdf8db314 > n/a (systemd) >#37 0xdf8db9aa > n/a (systemd) >#38 0xdf8da72f > n/a (system
[gentoo-hardened] Official project position on grsecurity change in release policy?
Howdy, Perhaps I missed it, but I've been so far unable to find a position/plan for the future of hardened-sources from the Gentoo Hardened project members. I've searched the site and mailing list archives. Has any such statement been made? I see there are some efforts to create a community maintained version of the PaX/Grsecurity patchset[1][2], this seems to be a likely forward course, but is integrating it the plan of the Hardened project or does that remain to be seen? [1]: https://github.com/thestinger/linux-hardened [2]: https://wiki.gentoo.org/wiki/Hardened_Kernel Thanks for any additional insight you might provide, Max -- 0x7D964D3361142ACF
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On Fri, May 12, 2017, at 16:38, Alex Efros wrote: > Hi! > > On Fri, May 12, 2017 at 09:10:43PM +0200, "Tóth Attila" wrote: > > Please take a look at on the reply of PaxTeam postend on the openwall > > mailing list: > > http://openwall.com/lists/kernel-hardening/2017/05/11/2 > > What's for? It's pointless. Only very few people are really interested > (i.e. not just curious) in knowing who is paid by which company for doing > what, who makes more real bugs, and who lies about something. > > The important questions about how to keep current level of protection for > individual/small business users and how users of some distributions like > Gentoo/Ubuntu/Android can be protected with GrSec/PaX are still > unanswered. > > While large companies may buy subscription for GrSec/PaX the mentioned > above categories of users can't (correct me if I'm wrong, please) - so > effectively the change in GrSec policy makes harm and punish mostly these > categories of users. If that's real GrSec/PaX goal - it's very sad but > they probably have rights to do this (except their public reasoning > doesn't match what they actually do, so probably there are some unsaid > reasoning exists too), but if it's not their real goal - then they > probably should provide some options for these categories of users too. > > -- > WBR, Alex. Individuals can certainly request a quote -- I did -- their director of sales is very patient, considerate and accommodating. Unfortunately the price is quite a bit more than I can personally afford at present. I don't personally doubt PaXteam/Spenders stated reasoning. It appears they've encountered a quite aggravating situation with what may amount to plagiarists. The post Dr. Toth linked closely mirrored what I initially anticipated from observing kspp and the like from afar. I think they're in a crap situation and what they've done is one of the better of several bad options. So, I am considering the costs of alternative control environments for my personal systems, perhaps it will be worth the quoted price after all once I've assessed options. But, point being, if paying is not out of the question I think you should request a quote. -- 0x7D964D3361142ACF
