It always make me sad when I hear BSDs are underfunded, OpenBSD was about to "turn off the lights", FreeBSD was in sersious problems before they got 1M$ donation from WhatsApp. Heartbleed bug in OpenSSL? They also didn't have enough (full time) developers to even review the code. Now grsecurity makes me feel bad about it.<p>Everyone uses their software, firewalls, servers, email serves, openssl is everywhere, corporate/bank cluster without BSD or Linux with grsecurity is unimaginable.<p>I recently started donating to opensource project I use everyday. I realised how little they ask for, F-Droid, I easily doubled their BTC found used to cover server maintenance, LibreOffice asks for 3EURO donation by default (also BTC)! OpenBSDFundation asks for 10$ per month.<p><a href="https://grsecurity.net/contribute.php" rel="nofollow">https://grsecurity.net/contribute.php</a><p>Edit: I also found a nice way how to donate to Tor, there is a site <a href="https://oniontip.com/" rel="nofollow">https://oniontip.com/</a> where you can donate others for running Tor nodes, one of two top 200nodes has WikiLeaks BTC address, another one goes to my wallet and I send it back to TorProject. I had enough free resources, I used them :)
Aye, too many people have this defeatist attitude that since perfect security will never be possible, therefore the only valid solution is reactive security (bug-patch cycles). Patch dependence is considered too entrenched for making some changes like replacing ambient authority with capabilities, using failure-oblivious computing [1] to redirect invalid reads and writes, using separation kernels, information flow control, proper MLS [2], program shepherding for origin and control flow monitoring [3] and general fault tolerance/self-healing [4].<p>I used to look up to Linus Torvalds as many did, but am increasingly beginning to see him as a threat to the advancement of the industry with his faux pragmatism that has led him to speak out against everything from security to microkernels and kernel debuggers.<p>[1] <a href="https://www.doc.ic.ac.uk/~cristic/papers/fo-osdi-04.pdf" rel="nofollow">https://www.doc.ic.ac.uk/~cristic/papers/fo-osdi-04.pdf</a><p>[2] <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.366&rep=rep1&type=pdf" rel="nofollow">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52....</a><p>[3] <a href="https://www.usenix.org/legacy/events/sec02/full_papers/kiriansky/kiriansky.pdf" rel="nofollow">https://www.usenix.org/legacy/events/sec02/full_papers/kiria...</a><p>[4] <a href="https://www.cs.columbia.edu/~angelos/Papers/2007/mmm-acns-self.pdf" rel="nofollow">https://www.cs.columbia.edu/~angelos/Papers/2007/mmm-acns-se...</a>
<i>There's no real leadership in Linux as far as security goes from within the kernel community itself.</i><p>I'm beginning to get the impression this (in general, not just for Linux) is because the talented security folks rather just do the fun parts. It'd be really awesome if more security conscious people were like the OpenBSD developers and worked on products, not just security.<p>I got into software through security. Getting a dump of my high school's faculty and staff password database was my first high and I chased it for years. My current job is in engineering where security is part of, but not all of, my focus. Since taking on this role, I've started feeling alienated participating in the "security community."<p>Work isn't always fun in the moment, work is sometimes just work. There seems to be a gap between how much work the "security community" wants to be able to push on the rest of the open source developer's plate, and how much those developers are willing to take. Security already (rightly) gets a shortcut over a lot of things, but it takes man-hours to make security happen.<p>Why can't it be the security guys? If spender doesn't want to send his kernel patches through the same review and legal processes the rest of us do, that's his problem. Why doesn't he stand up and become that security leadership in the kernel? Of course the submission process could be better, and of course he's not going to get everything he wants from the other maintainers right away... because it's <i>work,</i> and <i>work</i> isn't always fun.
Perhaps the way to push security into the industry is to use consumer's rights to their full capacity.
In the EU if you buy something, you get 6 months of warranty and 24 months of implied warranty.<p>If you buy an Android phone and stop getting updates after 18 months and there is a new security hole, you should return the phone to your dealer and demand your money back. After all, it's relatively easy to prove that the defect (the security hole) was already present when you bought the phone. The dealer must fix the defect. If he can't, he must take back the article. He will then complain to the manufacturer. The pressure from these complaints hopefully lead to a change of behaviour by the manufacturers (i.e. provide two years of security updates, for example, even if you buy a new phone that's already been available for a year or two).
This is the Washington Post interview he wrote this for: <a href="http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/" rel="nofollow">http://www.washingtonpost.com/sf/business/2015/11/05/net-of-...</a><p>Source: <a href="https://twitter.com/grsecurity/status/662393322699415554" rel="nofollow">https://twitter.com/grsecurity/status/662393322699415554</a><p>> Very fair article on the topic of Linux security: [...] … Was a pleasure talking with @craigtimberg
> The industry is entirely broken in terms of what it values.<p>Couldn't agree more. I feel that we, as entire IT industry, have failed to provide robustness, security, and privacy after dozens of years of development of Internet technologies. Just take the recent vulnerabilities in Android and iPhones, used everyday by millions of people worldwide. How could that happen after so many billions of dollars invested in the development of the major technology used nowadays? We failed miserably and don't even understand the root problems.<p>Of course, completely different thing is functionality: here we've seen tremendous improvements over the years - which is very positive - but that's another story.
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.<p>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.<p>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.<p>I think the primary way we will be able to move to <i>security</i> 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).<p>This is one reason why I find minix 3 to be a very interesting project, at <10k loc.
Grsecurity languishes in (relative) obscurity because no distribution ships it. I know several people who know about it and would pick the option if it was distro-supported. If you don't get automatic updates it's a non-starter.<p>Popularity in distros would put a lot of pressure on the mainline kernel and might get things moving there.
The Gentoo Hardened Project makes using grsec/PaX relatively easy. <a href="https://wiki.gentoo.org/wiki/Project:Hardened" rel="nofollow">https://wiki.gentoo.org/wiki/Project:Hardened</a>
See also this story: <a href="https://grsecurity.net/announce.php" rel="nofollow">https://grsecurity.net/announce.php</a>.
There is no monolithic upstream organization. The real problem is that it's really hard work to upstream code, particularly when it touches core parts of the kernel. Look how long it took to get other invasive stuff like tickless or preempt RT.
But it got done, it just took time and patience.<p>And insulting the upstream people like this doesn't make your job any easier.
I would think that everyone here agrees that 'computer' security is in a state of turmoil. Is it possible to design a computing system that fails-safe in the event of a bug in a component, instead of opening the entire system up to exploits. Fails Safe as in the process does nothing or restricts the targeted surface area of the malware.