Kernels job is security so why avoid more features till the user decides to add them?

There are thousands of different things available that could be tied to your kernel. Only those things deemed useful to all that meet other criteria (e.g. truly open source) would be embedded in upstream kernel. You'd have to write the kernel team to determine what they like or dislike about grsecurity or if they've even heard of it.

Based on what I just saw on their site about how they will only provide stable for paying customers it doesn't sound to me like it passes the smell test for truly open source:

Its a bit like when the president of Peru forcefully closed down Peru's legislature. You can't protect Democracy by overthrowing it and you can't protect Open Source by closing it.

Grsecurity complained that they could never get their code upstream. But kernel replied that they need to submit patches just like everyone else does. Grsecurity replied it was too difficult to submit patches. Grsecurity always blames upstream for not taking their patches but grsecurity never submits the patches.

Probably grsecurity never intended to submit patches but just tried to spin things to look like upstream was the problem.

1 members found this post helpful.

So my question becomes: Despite all of the hooey does grsecurity offer any measurable increase in overall system security? And I mean in totally b/c nothing is perfect. In addition to whatever positives it brings to the table what are the system level draw backs besides the stability issues going forward. I.E. what does it break, if anything?

We don't use it and based on what I've seen on looking into it since your initial post makes me leery of doing business with them. Ethics are a more important consideration than utility IMHO. I can't say they're definitely unethical since I've never done business with them and hadn't heard of them before your initial post but my brief look at them makes me uneasy.

I don't know anything about them, but if I heard that they "do not play by the rules" with regard to kernel patches and/or modifications to the kernel environment, I would for that reason alone immediately dismiss them. I would consider that they are either attempting "security by obscurity," or "security by 'just trust me,'" neither of which are sound security practices.

I am ok with security by obscurity. We all engage in that every day, all the time. The "just trust me" notion was rejected by kernel devs.

Oh the kernel itself benefits from security by obscurity to a degree. Right? Only the very best analysis by very smart devs will know the exploits that exist in the kernel and be able to use them transparently.

The sheer code volume makes it impossible to know/find all the kernel bugs and that is why I say security thru obscurity applies to the kernel. And really any OS because the amount of code. Most of which has never had a comprehensive audit.

... whereas "I am 'emphatically not(!)' prepared to accept such a notion.

Remember that we are all talking about 'security.' Which is, by definition, "the practical ability to protect your system from those who would do it harm." In my opinion, it is impossible for "someone 'else,' who seeks to conceal the means by which he (claims to ...) achieve what he (claims to have ...) achieved," to have done more than "the people who wrote the damn thing," and who by-design conceal nothing.

Unstable is still available, Gentoo is using it. They got pissed off because embedded computing industry used widely their code but didn't show any gratitude.

Yes, they put that rationale on their site but as I said before you don't defend "open" source by "closing" source.

I wonder what gratitude they expect or were expecting?

I think they ignored license requirements. See the grsecurity website for more precise information.

There's another big problem with grsec and that is the idea expressed by most of the kernel devs including Linus. The kernel has bugs fixing the bugs improves security. The whole idea of the security of the kernel is viewed as the wrong way to look at the problem. grsec should report bugs to the kernel and propose them in the way that the kernel dev community reports them.

There is also another side to opensource that I haven't followed closely. That side is that most all of the kernel devs are paid by someone to hack on the kernel. Maybe grsec is _not_ getting paid by anyone and so they are cashing in on their intellectual property by releasing it commercially only.

Maybe grsec has a valid position afterall because they have no benefactor as do the large majority of kernel devs.

BTW someone keeps track of the contributors to the kernel, I think it's Greg K-H.

Haven't you ever wondered who pays Linus' salary?

As a retired security technician, I can guarantee that most claims about security are misleading at best, and fraudulent at worst. They often accomplish the opposite of what you might think. This includes most computer security methods.

And when did "security" become the kernel's job? That's like saying "the government should do something..."

Congratulations on ridiculing yourselves.

https://twitter.com/grsecurity/statu...68572878176258

1 members found this post helpful.