Live data from Hacker News

Grsecurity Developer Spender's Feelings on the State of Linux Security

grsecurity.net

71–80 of 80 posts

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#71
post #19

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. Everyone uses their software, firewalls, servers, email serves, openssl is everywhere, corporate…

Most of us can afford to pay it too. That's the real tragedy. 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.

> Most of us can afford to pay it too. That's the real tragedy.

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.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#72
post #40

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 co…

The concept you list are orthogonal to most sources of kernel vulnerabilities and most of grsecurity's defenses: C-related exploitable memory safety bugs. grsecurity's C exploitation mitigation tech is just a band-aid for these. 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...

Yeah, but you get really far by eliminating memory and control flow attacks. There's also relatively cheap ways to do that with hardware and software. There's even schemes like SAFEcode/SVA, Code Pointer Integrity, and Softbound + CETS that do it automatically with a performance hit many apps can take.

Yet, what's uptake of such methods in mainstream, kernel development? There's the problem.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#73

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.

There were systems that did that all the way down to hardware in the 1960's with many more since:

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. :)

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#74

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…

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.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#75

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…

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.

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.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#76
post #2

Well there is no Linux security. L4 provides that.

Upvoting you because the first statement is right: there is no Linux security. Why? Security at a minimum requires a formal policy of what it's to achieve along with evidence the design meets that policy. Linux never had it. It's track record for flaws goes way in the opposite direction, too. So, it's insecure by default until proven otherwise and that might not even be possible due to complexity.

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...

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#77
post #40

Earlier quoted context omitted.

The concept you list are orthogonal to most sources of kernel vulnerabilities and most of grsecurity's defenses: C-related exploitable memory safety bugs. grsecurity's C exploitation mitigation tech is just a band-aid for these. 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...

Yeah, but you get really far by eliminating memory and control flow attacks. There's also relatively cheap ways to do that with hardware and software. There's even schemes like SAFEcode/SVA, Code Pointer Integrity, and Softbound + CETS that do it automatically with a performance hit many apps can take. Yet, what's uptake of such methods in mainstream, kernel development? There's the problem.

Or you could just use a memory safe language instead of getting into the C mitigation arms race.

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.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#78
post #77

Earlier quoted context omitted.

Yeah, but you get really far by eliminating memory and control flow attacks. There's also relatively cheap ways to do that with hardware and software. There's even schemes like SAFEcode/SVA, Code Pointer Integrity, and Softbound + CETS that do it automatically with a performance hit many apps can take. Yet, what's uptake of such methods in mainstream, kernel development? There's the problem.

Or you could just use a memory safe language instead of getting into the C mitigation arms race. 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.

I agree: my main recommendation for new projects. However, avoiding C or porting Linux/BSD to a safe language fell on deaf ears for decades. So, for them, I recommend techniques that work with C and UNIX architecture. Maybe more progress that way.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#79

Earlier quoted context omitted.

Most of us can afford to pay it too. That's the real tragedy. 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.

> Most of us can afford to pay it too. That's the real tragedy. 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.

Please, please donate to the library developers. Scan the dependencies for some of your favourite packages and see if there's anything common to a few that might not be obvious. SDL backs so many things, for example, but rarely gets called out.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#80
post #29

Earlier quoted context omitted.

Grsecurity's approach is superior to OpenBSD's, but both are acceptable. 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).

Some interesting insights on Grsecurity's approach by OpenBSD's Nick Holland in the comments section: https://www.digitalocean.com/community/tutorials/an-introduc...

He's actually talking about the SELinux/"RBAC in general" approach. His only criticism of Grsecurity is that it's not in the mainline and therefore not as effective as it could be.
Post reply on HN