Grsecurity Developer Spender's Feelings on the State of Linux Security
grsecurity.net
grsecurity.net
Everyone uses their software, firewalls, servers, email serves, openssl is everywhere, corporate/bank cluster without BSD or Linux with grsecurity is unimaginable.
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.
https://grsecurity.net/contribute.php
Edit: I also found a nice way how to donate to Tor, there is a site https://oniontip.com/ 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 :)
All of us should consider doing something similar, allocate a couple $ a month and give it to people who make our lives/jobs easier or better.
I think the hardest part for me is: I use soooooo much open-source software, that I can't contribute to all of them. Don't get me wrong, I should contribute more than I do, and I'm not excusing myself, but it's a legitimate problem. I'm sure people smarter than me have debated models for this, but I still don't think we have a good answer.
FreeBSD is actually behind Linux - it lacks an effective access control framework and did not have ASLR until the latest release. At least they're working on it (TrustedBSD, Capsicum).
how many people ever bother to write and deploy a trustedbsd policy: (to first order approximation) nobody
Defaults matter, a feature matrix checkbox is simply deceptive because the fact something isn't on (and configured) by default often means its an insane amount to work to try to enable it and/or thing are unfixably broken when you do (from a user point of view)
unfortunately both these things are true of trustedBSD
LOCK System http://www.cyberdefenseagency.com/publications/LOCK-An_Histo...
Sidewinder firewall http://www.ittoday.info/AIMS/DSM/83-10-35.pdf
Flask project/architecture https://www.cs.utah.edu/flux/fluke/html/flask.html
Nonetheless, the old stuff (esp LOCK & LOCK/ix) are still stronger in security architecture and design despite all these years. Good design is timeless I guess. :)
Note: Cambridge's CHERI project and CheriBSD are the cutting-edge for FreeBSD security as they do capability-security from hardware up with FreeBSD already ported. Also supports Capsicum, Flask, and separation kernels if one wanted. True integration of each major branch of INFOSEC. :)
Fortunately, the best security approaches (HW-centric) are portable to both w/ FreeBSD getting most prototypes. You can already run capability-secure FreeBSD via Cambridge CHERI project. Criswell's people are doing lots of stuff with FreeBSD and maybe Linux:
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
http://sva.cs.illinois.edu/pubs.html
Examples for Linux include these:
http://scholar.lib.vt.edu/theses/available/etd-10112006-2048...
https://web.archive.org/web/20120509155852/http://archives.e...
https://docs.google.com/file/d/0B1i_Zf52vJctMTA4YTI1MmUtNzdj...
That doesn't even include software-related techniques like microkernels, low TCB software, safe low-level languages, and automatic compiler transformations for security that neither are adopting. They're both low-medium assurance by my standards due to cultural refusal to apply what's proven to work. So, I already have predictions about tech-transfer of papers above to Linux/FreeBSD use at large. You can probably guess how optimistic I am. ;)
https://www.digitalocean.com/community/tutorials/an-introduc...
https://www.digitalocean.com/community/tutorials/an-introduc...
And here is the referenced email with a bit of context:
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.
[1] https://www.doc.ic.ac.uk/~cristic/papers/fo-osdi-04.pdf
[2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52....
[3] https://www.usenix.org/legacy/events/sec02/full_papers/kiria...
[4] https://www.cs.columbia.edu/~angelos/Papers/2007/mmm-acns-se...
At the time he was against microkernels it would be fair to say monolithic kernels did definitely have (and continue to have) performance advantages over microkernel architectures. Have things changed? Somewhat. Some of how OS kernels are used has changed and that has made microkernels more attractive again.
I feel the rest of your argument just feels like the jab at Linus is tacked on though because he doesn't seem to be against capabilties system. (infact the kernel has what? 3 capabilities systems?) Nor does he seem against forms of multi-level security or program shepherding. So maybe those weren't meant to be directed at him.
Either way I just wanted to say that people should give him some slack, his job isn't to please security zealots but to ship software all of us use and many of us depend on for our livelihood in a timely and reliable manner.
Linux does not have any form of capabilities (maybe Capsicum, but it's not finished). Capabilities are not POSIX capabilities, which redefined a decade-old term, but rather this [2].
The rest is just trite dismissals of the same faux pragmatism that Linus embodies. He's "not interested in the theoretical", as if there is any other? Before the now-mundane ideas became the staples of pragmatists, they were theories hidden in the research literature.
Linus is a major figurehead and his promoting of self-destructive attitudes is undesirable.
In fact, you claim he lives in the here and now. He does not. The here and now has long surpassed him and he now lives in his own realm.
[1] https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.p...
Linus holds the vast majority of the blame here, simply put, he is an idiot when it comes to security or looking ahead at how things will be in a couple of years. Linux is slowly entering every single aspect of our lives and this trend will only accelerate via IoT. Imagine what this means about security with Linus in charge.
We now KNOW that there are intelligent adversaries out there that spend hundreds of millions to defeat security worldwide. It is simply UNACCEPTABLE and downright MALICIOUS STUPIDITY for Linus to hold the views he does in this day and age. He's been repeatedly warned and cautioned for more than a DECADE now and he's laughed at and ignored valid criticisms from people with much more foresight than him. If this trend continues, he should be NAILED to the cross.
A security bug is NOT just a bug.
No, I shouldn't have to DISCONNECT everything that runs Linux from the Internet if I want it to have a modicum of security.
Do you have some details on this? I did not realise the situation was so bad.
So, one could say it's pretty bad even if the "many eyes" and code audits are finding/fixing a ton. Simply too many to justify if their process is any good. An recent example I found was the Saturn project throwing an automated tool at it and finding 100+ real bugs in one go.
Do you have recommended reading or links so that I can get up to speed?
Here is a recent example where PaX team are called "leeches" by a maintainer: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-A...
If this sort of attitude is not stupid, I don't know what is. These people can't see the forest from the trees.
Meanwhile, systems like THE (Dijkstra), Burroughs B5500, IBM System/38, GEMSOS (Schell), RC4000 (Hansen), MULTICS, KeyKOS (Bomberger et al), and VAX VMM Security Kernel (Karger/Lipner) showed how to design and implement systems with ultra-high reliability and/or security. These lessons were mostly ignored time and time again even when they could be applied. User-mode drivers and languages with pointer/buffer/stack protection would have by themselves prevented ridiculous amounts of problems. I heard that, after around 2-3 decades, the UNIX crowd is adding some user-mode drivers. See the problem?
Note: Far as lightweight systems & adaptivity, you should see the work of Brinch Hansen, Niklaus Wirth, and Andy Tannenbaum. They applied safe, modular techniques on systems with less resources than today's. UNIX and Linus resist for both personal preference and inertia, not valid technical objections.
Yes, I've heard this implied before. This is effectively doing the adversary's work for them, and for free! Perfect truth is never attainable, therefore let's not do science?
To put it in more positive terms, achieving perfection is not important. What is important is a continual methodical process to keep improving, that more-than-offsets natural tendencies to deteriorate. In software engineering terms, it means not letting the project grow to a state where the exploit-discovery rate is so high. Since exploits generally affect the entire kernel, it's negligent and reckless, to be satisfied with merely keeping the bug-per-SLOC ratio constant.
Of course a kind of Amdahl's law applies to these: eliminate memory safety related vulnerabilities, capabilities and such become important in eliminating the rest of the bug classes...
Yet, what's uptake of such methods in mainstream, kernel development? There's the problem.
Time and time again mitigation techs have gotten widely deployed, exploits have caught up, it's a perpetual cycle. Yes the exploitation gets a little harder each time around, but you don't get sound memory safety that way.
My point wasn't the specific proactive mitigations, but rather Linus' attitudes creating negative perceptions.
People should keep barking given how much depends on the project now. Plus support alternatives that take better approaches to architecture like old EROS, MINIX 3 (reliability), or GenodeOS (security/reliability). Safe native approaches like security-enhanced Oberon System or JX Operating System would also kick butt. Each achieved certain robustness properties in mere years with small teams due to good design.
UNIX and Linux took decades to get usable, still give hackers MB of opportunities for kernel attacks, and still crash my systems on occasion. Meme: "Failure to learn the lessons of the past and apply them."
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.
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."
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.
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 work, and work isn't always fun.
If other opportunities are there for someone with a security skillet, what makes a libfoo maintainer become skilled enough to make the most secure libfoo possible, but also stay on libfoo? Does saying "security is important" mean that security is important, or does it means "have my skillset, and also do the busywork someone with my skillset is able and happy to ignore?"
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).
The plan for allowing a device to be free from defects for two years since date of purchase is good; since date of announcement is practically worthless, unless companies start announcing products and then waiting a year to release to shorten their support time?
Source: https://twitter.com/grsecurity/status/662393322699415554
> Very fair article on the topic of Linux security: [...] … Was a pleasure talking with @craigtimberg
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.
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.
Or maybe that it's just cost effective to have others do the work for you?
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.
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.
Relevant papers for it here:
https://news.ycombinator.com/item?id=10522894
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.
Popularity in distros would put a lot of pressure on the mainline kernel and might get things moving there.
I used to make my own Linux distribution, from scratch, with Grsecurity, PaX/RBAC for everything.
Then it wasnt so usable, when I needed new packages/software, or upgrades, compiling was tiresome, and I didnt know how to make a package manager, or how to automate everything.
I assumed somebody else would do it, a big multi billion dollar company perhaps, since I was just 16 year-old doing that over a summer, they would do better, right?
Oh how sad. Nobody really cares about security.
Since, enterprises just use lawyers instead of security.
I'm not well versed enough to understand whether "Just using pie binaries to enable proper ASLR" is included, but the chart does show green against various things mentioning ASLR. It looks like specific packages are built with PIE, too.
And insulting the upstream people like this doesn't make your job any easier.
The upstream people are pretty wedded to the idea that throwing insults is a reasonable response to frustration with poor behaviour. They do not have any legs to stand on re: hurt feelings.
Key statement "Specific type of failure". In theory any particular piece of large software has tens of thousands of fail safes in it all ready. For example, when you send an oversized buffer to an application with input checking it does not explode in a ball of flame (unlike programs from the '90s) and warns you about the problem. But that is where the analogies break down between mechanical items and software, software is far more connected internally than almost all other machines are.
https://www.schneier.com/blog/archives/2014/04/dan_geer_on_h...
Market rejected them because they cost a bit more or didn't have highest, raw performance. Such short-sightedness means most done exist any more in any turn-key form. Many of the modifications are straight-forward enough that even academics are prototyping them and porting Linux/FreeBSD to them.
https://news.ycombinator.com/item?id=10522742
Mainstream just refuses to learn or adopt proven methods of the past. They use every justification in the world even when the labor is free (FOSS) with someone only asking to use the minimal of proven techniques. Market rarely buys the stuff outside very limited sales of some robust appliances: see Aesec's GEMSOS stuff, SAGE Guard on XTS-400, Nexor Mail Guard (on XTS-400), Green Hill's INTEGRITY-178B OS w/ virtualization, Mikro-SINA VPN on L4, Secure64's SourceT OS for DNS, Sentinel's HYDRA firewall (uses INTEGRITY), and so on. Social, political, and economic problems rather than technical. I see no end to it outside continued sales and development of niche solutions.
Note: The things I referenced in last paragraph are either still on the market w/ descriptions available via Google or at least have papers in reach. I left out tons of good stuff that's no longer around or just a prototype. Happy Googling and learning. :)
L4 provides that.
Combinations of micro/sep kernels and paravirtualized Linux... from L4 projects to commercial like LynxSecure... at least have a start on a security via isolation argument. A start...