Live data from Hacker News

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

grsecurity.net

31–40 of 80 posts

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

#31
post #18

Earlier quoted context omitted.

I wouldn't be so harsh. Linus thinks and works in the here and now. He is neither interested in the theoretical or bothered by what theoretical people have to say about him. He ships code that works and works well and generally speaking has a good security track record compared to many userspace systems (Adobe Flash anyone?). At the time he was against microkernels it would be fair to say monolithic kernels did defin…

No, nobody should give Linus any slack whatsoever. He's responsible for the current fiasco, where stock Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours, once the debugging infrastructure is there. Compare that with Windows where it's a few weeks to a few months and then a lot more work to get the reliability. Linus holds the vast majority of the blame here, simply put, he is…

> Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours

Do you have some details on this? I did not realise the situation was so bad.

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

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

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

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

#33
post #18

Earlier quoted context omitted.

I wouldn't be so harsh. Linus thinks and works in the here and now. He is neither interested in the theoretical or bothered by what theoretical people have to say about him. He ships code that works and works well and generally speaking has a good security track record compared to many userspace systems (Adobe Flash anyone?). At the time he was against microkernels it would be fair to say monolithic kernels did defin…

No, nobody should give Linus any slack whatsoever. He's responsible for the current fiasco, where stock Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours, once the debugging infrastructure is there. Compare that with Windows where it's a few weeks to a few months and then a lot more work to get the reliability. Linus holds the vast majority of the blame here, simply put, he is…

I am unaware of the security warnings etc. against Linus and Linux in general as I am a bit out of touch with Linux, having moved to OSX a few years back.

Do you have recommended reading or links so that I can get up to speed?

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

#34
post #29
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…

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

FreeBSD supports Mandatory Access Control, implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as Biba and Multi-Level Security.

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

#35

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…

> perfect security will never be possible, therefore the only valid solution is reactive security

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.

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

#36

Earlier quoted context omitted.

No, nobody should give Linus any slack whatsoever. He's responsible for the current fiasco, where stock Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours, once the debugging infrastructure is there. Compare that with Windows where it's a few weeks to a few months and then a lot more work to get the reliability. Linus holds the vast majority of the blame here, simply put, he is…

I am unaware of the security warnings etc. against Linus and Linux in general as I am a bit out of touch with Linux, having moved to OSX a few years back. Do you have recommended reading or links so that I can get up to speed?

Did you read the linked article? Grsecurity people, gentoo security people and other security insiders have been urging Linus and other maintainers to change their views for decades. Nothing has happened except plenty of hand waving and ridicule. Visit the grsecurity forums, the IRC channel for more details.

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.

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

#37

Earlier quoted context omitted.

No, nobody should give Linus any slack whatsoever. He's responsible for the current fiasco, where stock Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours, once the debugging infrastructure is there. Compare that with Windows where it's a few weeks to a few months and then a lot more work to get the reliability. Linus holds the vast majority of the blame here, simply put, he is…

> Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours Do you have some details on this? I did not realise the situation was so bad.

[deleted]

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

#38
post #32

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

That's a very interesting point, and a good idea! It does put the onus on us as developers to ensure we do a good job and get it right from the beginning, which can only be a good thing.

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?

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

#39

Earlier quoted context omitted.

I am unaware of the security warnings etc. against Linus and Linux in general as I am a bit out of touch with Linux, having moved to OSX a few years back. Do you have recommended reading or links so that I can get up to speed?

Did you read the linked article? Grsecurity people, gentoo security people and other security insiders have been urging Linus and other maintainers to change their views for decades. Nothing has happened except plenty of hand waving and ridicule. Visit the grsecurity forums, the IRC channel for more details. Here is a recent example where PaX team are called "leeches" by a maintainer: http://lists.infradead.org/piper…

Ah more reading required. Thanks!

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

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

Post reply on HN