Live data from Hacker News

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

grsecurity.net

51–60 of 80 posts

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

#51
There's no real leadership in Linux as far as security goes from within the kernel community itself.

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.

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

#52

There's no real leadership in Linux as far as security goes from within the kernel community itself. 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. Getti…

[deleted]

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

#53

There's no real leadership in Linux as far as security goes from within the kernel community itself. 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. Getti…

Talented security folks, especially those that can engineer security rather than penetration testing, have so many opportunities that fighting an uphill battle on mailing lists just isn't very attractive.

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

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

Some interesting insights on Grsecurity's approach by OpenBSD's Nick Holland in the comments section:

https://www.digitalocean.com/community/tutorials/an-introduc...

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

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

Link directly to the comment:

https://www.digitalocean.com/community/tutorials/an-introduc...

And here is the referenced email with a bit of context:

http://osdir.com/ml/general/2014-02/msg44493.html

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

#56

Earlier quoted context omitted.

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.

and how much of the system is protected by trusted bsd by default: none of it 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 (…

The TrustedBSD features are used by appliance vendors who base their product on FreeBSD. Applicances have very narrow profiles of acceptable use and thus it's actually sane to develop policies for them.

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

#57
post #53

There's no real leadership in Linux as far as security goes from within the kernel community itself. 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. Getti…

Talented security folks, especially those that can engineer security rather than penetration testing, have so many opportunities that fighting an uphill battle on mailing lists just isn't very attractive.

That's part of my point. As long as the work is "someone else's problem," will it ever get done?

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?"

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

#58
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 think that your tone will turn a lot of people off, which is why you've been downvoted (by others), but I think that what you said needs to be heard, especially re: IoT. It's a nightmare waiting to happen.

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

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

And insulting the upstream people like this doesn't make your job any easier.

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

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

MinGW-w64 also lacks ASLR and DEP. As a result most FOSS Windows packages lack them as well:

https://sourceware.org/bugzilla/show_bug.cgi?id=19011

Post reply on HN