I've been follow grsec for a while now, and I really like the honesty around it. They admit what they are and aren't good at, and as for the product itself (grsec), it has become my go to hardening system for the kernel over SELinux (I know you can combine the two, I don't though). Combined with other measures I think I am doing a pretty good job in balancing out the usability security scale.
If you haven't taken the time to learn grsec, you will thank yourself later if you do. Keep in mind though there was some recent drama with some people/companies not properly attributing grsec, so you want to use current instead of stable imho. Alpine linux has grsec build in, gentoo has some good guides, and so does arch, but I tend to add it to debian.
As far as the state of linux/kernel security, I blame one thing in particular, and that is complexity and amount of code. The many eyes theory has a fault, in that it assumes a lot of people will look at the code and with enough people the bugs (security bugs) will be found. Well the problem is that the linux kernel is now at 10 million+ loc. So even with a shitton of people digging through the code, lots of stuff is going to get missed, and the real problem is that there are a lot less people looking at the code than we all want to think.
I think the primary way we will be able to move to security in the future is in efforts to refactor and reduce complexity of code in general, along with working on making it easier to read (or better commented).
This is one reason why I find minix 3 to be a very interesting project, at <10k loc.
Good points. Far as SELinux and grsec combined, it might help if you know what Type Enforcement is really supposed to do in practice. It's not just isolation like rule-based control. The most powerful things about it were "assured pipelines" that could deal with transitive issues or force things to happen somewhat in order.
LOCK platform still kicks its successors' (esp Linux + SELinux) asses in many ways despite time passed. Just shows how little mainstream learns from the past or even present in terms of secure stuff in academia. Hope you enjoy the LOCK and CHERI designs if not FLASK, of which I'm not a fan either.
Get used to the Linux situation cause it's not going to change I think. The "many eyes" theory is downright stupid, because guess what, there are few if any eyes.
The eyes that are many are on the attacker side, extremely skilled individuals who have cut their teeth on the kernel for 15+ years.
On the defender side, apart from Google project zero (who are not just focusing on the linux kernel) and a few stray individuals, there is nobody looking for vulnerabilities in the kernel in order to make them public.
As far as complexity goes, Linus knows all of that which is why he's playing "catch the baby" or "throw the hot potato". I called him maliciously stupid in a previous comment and I think that's a fair characterization. He's not simply stupid, he knows the stakes and the sad state of affairs in the kernel (complexity, 0 security mindset, archaic architecture) and he sees the options available to him:
+ Make security top priority (as Microsoft did 10 years ago) which will expose him as a fool for his past mindset since that will amount to him admitting that he was dead wrong all these years. I don't think he has it in him to do this, he's too much of an egomaniac now.
It will also expose most of the kernel maintainers and developers as total incompetents when it comes to writing secure code and slow the pace of development.
+ Let others solve the problem. This is where Grsecurity/PaX comes in. That would necessitate him releasing a lot of control over the kernel into 3rd parties, since the best parts of Grsecurity are pretty intrusive and touch a lot of kernel components. I don't think he's willing to do that either.
+ Do nothing and deal with the problem by making idiotic statements of the sort "If you care about security, don't connect Linux to the Internet" or "insulate the kernel by adding layers of security such as sandboxes ...". In sort, he's saying it's not his problem STFU and deal with it yourself. These comments are idiotic because any sort of security person knows that you can't build a fortress on shifting and rotting foundations. You can pile as many sandboxes and intrusion detection systems you want, but they can all be bypassed if the kernel is weak.
So, to summarize, he knows he has a clusterfuck in his hands due to decades of
development with 0 security mindset and he's simply not willing to own up to it. He's throwing the hot potato to us and tries to shift awareness and focus away from the part he's directly responsible for.
If you haven't taken the time to learn grsec, you will thank yourself later if you do. Keep in mind though there was some recent drama with some people/companies not properly attributing grsec, so you want to use current instead of stable imho. Alpine linux has grsec build in, gentoo has some good guides, and so does arch, but I tend to add it to debian.
As far as the state of linux/kernel security, I blame one thing in particular, and that is complexity and amount of code. The many eyes theory has a fault, in that it assumes a lot of people will look at the code and with enough people the bugs (security bugs) will be found. Well the problem is that the linux kernel is now at 10 million+ loc. So even with a shitton of people digging through the code, lots of stuff is going to get missed, and the real problem is that there are a lot less people looking at the code than we all want to think.
I think the primary way we will be able to move to security in the future is in efforts to refactor and reduce complexity of code in general, along with working on making it easier to read (or better commented).
This is one reason why I find minix 3 to be a very interesting project, at <10k loc.