FYI: Kernel Hardening; a discussion (2018)

[sevas]

For those of you who are fresh like myself, Im going to compile some
information Ive found on Qubes Kernel hardening. And for the tech savvy Qubes
junkies, also like myself, lets have another discussion! Of course
anyones welcome to add their 2 cents or drop a dime.

~Things that I think are facts but might not be as of early 2018~

1. Qubes does not incorporate kernel hardening.
2. GrSecurity is really great security? (Discussion/opinion below)
3. The Coldkernel Team is working on Qubes kernel hardening.
4. GrSecurity is working close with PaX.

Q - Why should you care?
A - Kernel Hardening protects against many forms of L337 H4X0R5 and monsters.

~More pseudo-phacts~
5. "PaX is maintained by The PaX Team, whose principal coder is anonymous"
-cite: https://en.wikipedia.org/wiki/PaX

6. GrSecurity is really great security but very few distros use it.
-Why? An extrapolation on this below.

7. Q - Why is Qubes not integrated with GrSecurity/PaX?
A - "Grsec is dead (at least as an open source project), so it doesn't apply anymore." -marmarek (dev)

8. Q - How can we easily incorporate kernel hardening into our Qubes?
A - Directly into your qubes just like this:
https://coldhak.ca/blog/2016/12/12/coldkernel-qubes-1.html

~On GrSecurity/PaX~

GrSecurity, allegedly, is a really great form of kernel hardening. A
brief look at their wikibooks.org page tells you that they have done
their homework. Notably, there are features that Qubes users would
find very appealing. Upon further investigation, it seems as though
this is not an open source project, meaning that only the inner core
of developers works on maintaining and updating the code, but the
source is still free to distribute so long as its not changed, from
my understanding. (cont. below)

cite:
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options

GrSec doesnt keep their docs well maintained and the setup uses lots of jargon/acronyms that are not for modest users. -misquote, Qubes user, April 2017
-drawbacks to GrSec:
-you have to pay for support to keep up-to-date with patches
-the likely-hood of users scrutinizing the code is much smaller than open-source development

GrSec, while it sounds good, is aimed at a different breed of user-base.
I really like the idea of (excuse my lack of proper technical terms)
a non-profit that still gets paid. I have no idea how it actually works,
but I assume that people that believe in a presented idea donate and
developers get paid to preform a civil service. That is a really sound
business plan. Sure, lots of people do not donate. Alternately, lots of
people DO donate.

For instance, Kali Linux. They offer a free to the public open source
service: the hacking distro, originally Backtrack Linux. They needed
more money, so instead of living off of donations, they created the
OffSec brand training and certifications. OffSec and Kali: two mostly
different products that do not solely rely on each other. Or I should
say, Kali does not rely on OffSec.

The difference that Im hinting at is that GrSec does not support this
freedom. Its subtly obvious that between not keeping the documentation
up-to-date and the software itself being hard to understand, they have
made the open source 'project' extremely difficult for the end user. It
is only really feasible for enterprises.

To reiterate in a somewhat prejudice, unprofessional manner: Theyre not
open source because they believe in open source. Their heart isnt in it.

Back to business.

"In late June, noted open-source programmer Bruce Perens warned that using
Grsecurity's Linux kernel security could invite legal trouble."
-theregister.co.uk

pseudo-facts:
Bruce Perens posted a blog article in late June of 2017 that concluded that anyone who compiled their kernel using GrSec was subject to "contributory
infringement and breach of contract" due to the GNU policy declining the
modification of code. At first glance, it would seem that Perens did slander
this company and some would argue that this accusation would be a far-fetched
plausability for a company that is only insuring themselves. But as the
security community well knows and lawsuits have well-documented, corporations
often blur the lines between property dispute.

The month after Perens posted his blog, the stated company lashed back
as would a person deeply hurt by critique. I wouldnt think that slander
would warrant a lawsuit, but a lawsuit it was accusing Bruce, his webhost
and others of defamation and business interference. This does not make them
stand out from other companies. After all, Cisco sued DefCon in 2005 for
similar reasons of exposing vulnerabilities in their routers. But this is
the nature of what makes security SECURE. Exposing loopholes and plugging
them. And this company acted with a most unbecoming maturity.

cite:
https://www.theregister.co.uk/2017/08/03/linux_kernel_grsecurity_sues_bruce_perens_for_defamation/

The software is licensed under the GNU GPL version 2 meaning the software
is free to distribute as is. The cited article also declares that Perens
accuses the company of over-ruling the license agreement by stating that
customers who distribute the subscription patches will forfeit their
customer rights.

GNU GPL v2 section 6: You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

If youre still thinking about using this obviously robust software, I
will conclude by restating that GrSec does not have the consumers best
interests in mind. And this the the most important consideration when
deciding whether to use a product. It should also be well noted that
when googling 'GrSec', there are many concerns.

Hardened Linux stalwarts Grsecurity pull the pin after legal fight
https://www.theregister.co.uk/2015/08/27/grsecurity/

Linux kernel security gurus Grsecurity oust freeloaders from castle
https://www.theregister.co.uk/2017/04/26/grsecurity_linux_kernel_freeloaders/

Linus Torvalds slams 'pure garbage' from 'clowns' at Grsecurity
https://www.theregister.co.uk/2017/06/26/linus_torvalds_slams_pure_garbage_from_clowns_at_grsecurity/

My mail to the grsecurity team to expose their FUD
http://www.openwall.com/lists/kernel-hardening/2017/06/29/7

Beyond #Grsecurity: The Future of Linux security is Brighter than Ever
https://www.whonix.org/blog/beyond-grsecurity-future-linux-security-brighter-ever

[sevas]

I did not mean to go so far south with the above statements. So heres my
additions for alternatives...

CopperheadOS is doing a project still early in the making on reawakening
the open source kernel hardening. The GitHub page can be found here:
https://github.com/copperhead/linux-hardened/issues

...which are limited.

If anyone has any information on the ColdHak.ca kernel hardening project,
please let me know. I have sent messages to two of the ColdHak members and
am awaiting response. My question is about what features to expect in their
project. As their website has no information on what it actually does. As
well, the last and only update was from a little over a year ago, it does not
appear as if they are still working on this.

Update:
One of the members of the ColdHak Team has reached out to me. What was not understood was that the ColdHak Project was an automated tool for building
GrSec. The project was killed when GrSec closed the doors to open source
developing, as mentioned above.
above. There does not appear to be any active design for those who wish to
change the

[Tai...@gmx.com]

I don't see the issue with the pax devs being anonymous as then it is
much more difficult for someone to put political pressure on them to
demand they insert a backdoor or approve some type of undesired change -
ex: why do you think almost every linux distro switched to systemd
overnight?

[awokd]

On Sun, March 11, 2018 5:49 pm, sevas wrote:
> I did not mean to go so far south with the above statements. So heres my
> additions for alternatives...
>
> CopperheadOS is doing a project still early in the making on reawakening
> the open source kernel hardening. The GitHub page can be found here:
> https://github.com/copperhead/linux-hardened/issues
>
>
> ...which are limited.

I agree, it's disappointing grsecurity couldn't figure out a better way to
handle that.

You might find this interesting, though:
http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/

[sevas]

I do find that very interesting and Ive saved the website for further investigation a little later. Thanks for that!

[Tim W]

Yeh I recall when it was all coming to a head over on their forum. They tried IIRC legal action and pressure and costs were going to be debilitating thus I think that is why they did what they did. In fact I think in the end all they were looking for was recognition it was their code being used. It was some time ago and I might not be recollecting it all. But it was a big deal.

I really like the guys that make up copperhead. They also did what they had to keep the doors open and viable for their android os version. I paid the fee for the pixel to have them load to give my support to them. Soon they should have pixel 2 all done and I will pay them again to have it on a pixel 2. They strike a great balance for me between secure and usable. They do good work IMO.

Cheers,

Tim

[sevas]

I looked at that. Its a pretty cool direction. I had read some article that
said they were teaming up with a provider that offered end-to-end encryption
so you get the whole kit and caboodle. I wanted to install something less offensive on my galaxy, but it turns out Verizon phones are trash and cant even unlock the bootloader.

Purism is also doing cool phone stuff. A phone run on linux. So you can install
whatever OS you want. And a screen handling program to resize everything. They
also are working on the end-to-end angle.

I was unaware of the narrow options for kernel hardening and the drama. Just part of my research and