Re: Grsecurity is about to be discontinued...

[Robert Hancock]

atoth@xxxxxxxxxxxxx wrote:
> In Reply to Linus Torvalds on Grsecurity:
>
> These days people out there are running closed-source adobe flash plugin
> to browse pages like ebay.com where one can come across some applets
> causing execution attempts daily. It can be detected using improved
> techniques only.
> I don't care about what code will run on many noobs' machine, but I'd like
> to stay secure. So even if it seems insane, it surely makes sense -
> unfortunately.
> I suspect some of the most important improvements are labeled "annoying"
> by Linus. However some other operating system's board chose to include
> parts of such implementations (I won't list them here). It would be good
> to see as many snippets of PaX/Grsec in the mainline as possible. Please
> take this message as a sign, that Gabor Micsko (trey@xxxxxx) is not alone
> with his idea.
>
> Grsecurity proved itself as a viable, valuable solution for combined
> techniques for hardening Linux. I'm using a laptop which has every
> application running regulated by Grsecurity's RBAC system - including
> _all_ GUI apps. Please warn me, when there will be some security policies
> available to convert a targeted SELinux machine into a fully hardened
> SELinux box with GUI.
>
> I'm not sure, that putting Grsecurity in the mainline would save the
> project. I rather hope, that some companies using the software will give a
> helping hand to the developers. However the Linux community should turn
> its attention to defensive security solutions, IMHO. As it gets more and
> more abundant, there will be more exploits floating around. Some lessons
> can be learned from those "monkeys" on how to think secure.
>
> A polished full-featured security system can raise Linux above other
> solutions. The better if there are more possibilities to choose between.
> All features of PaX and Grsecurity can be disabled by default: so an
> ordinary user shouldn't worry about being secure.
>
> Please consider to think about how secure is your on system and what can
> be done to fix it. If some focused persons provide a specialized solution
> it worth to be investigated.

This is all very nice, but messages like this are not going to help 
anything. If those guys want to get code into the mainline kernel then 
the path for that is the same as for anybody else: concrete, 
step-by-step improvements (i.e. patches) that do not duplicate 
functionality that is already present in the kernel, actually belong in 
the kernel as opposed to userspace, and do not create an undue 
maintenance burden. If such patches were submitted they would 
potentially be accepted. Question is why the grsecurity guys haven't 
done this well before now, as opposed to now when they seem to be in 
crisis mode.

Saying to the kernel developers "here, throw this huge blob of code into 
your kernel because otherwise we're taking our ball and going home" is 
not how it works.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/