
Grsecurity Developer Spender's Feelings on the State of Linux Security - jsnathan
https://grsecurity.net/~spender/interview_notes.txt
======
akerro
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/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](https://grsecurity.net/contribute.php)

Edit: I also found a nice way how to donate to Tor, there is a site
[https://oniontip.com/](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 :)

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

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

[https://www.digitalocean.com/community/tutorials/an-
introduc...](https://www.digitalocean.com/community/tutorials/an-introduction-
to-selinux-on-centos-7-part-1-basic-concepts)

~~~
j_s
Link directly to the comment:

[https://www.digitalocean.com/community/tutorials/an-
introduc...](https://www.digitalocean.com/community/tutorials/an-introduction-
to-selinux-on-centos-7-part-1-basic-concepts?comment=17853)

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

[http://osdir.com/ml/general/2014-02/msg44493.html](http://osdir.com/ml/general/2014-02/msg44493.html)

------
vezzy-fnord
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].

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](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....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.366&rep=rep1&type=pdf)

[3]
[https://www.usenix.org/legacy/events/sec02/full_papers/kiria...](https://www.usenix.org/legacy/events/sec02/full_papers/kiriansky/kiriansky.pdf)

[4] [https://www.cs.columbia.edu/~angelos/Papers/2007/mmm-acns-
se...](https://www.cs.columbia.edu/~angelos/Papers/2007/mmm-acns-self.pdf)

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

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

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

~~~
nickpsecurity
I'm not sure objectively what the current state is. However, it's a little
known fact that Linux kernel specifically (due to fame) benefits from tons of
academic work on bug hunting tools. Every time they run a new one, they find
all kinds of problems that are preventable with a safer language or sound
architecture. Many of them would've been contained in a microkernel
architecture rather than have full access to memory.

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.

[http://saturn.stanford.edu/pages/papersindex.html](http://saturn.stanford.edu/pages/papersindex.html)

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

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

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

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

~~~
72deluxe
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?

------
_yy
This is the Washington Post interview he wrote this for:
[http://www.washingtonpost.com/sf/business/2015/11/05/net-
of-...](http://www.washingtonpost.com/sf/business/2015/11/05/net-of-
insecurity-the-kernel-of-the-argument/)

Source:
[https://twitter.com/grsecurity/status/662393322699415554](https://twitter.com/grsecurity/status/662393322699415554)

> Very fair article on the topic of Linux security: [...] … Was a pleasure
> talking with @craigtimberg

~~~
gozo
The comments in the HN submission must be some new record in middlebrow
dismissals.

[https://news.ycombinator.com/item?id=10515817](https://news.ycombinator.com/item?id=10515817)

~~~
epistasis
I think the article did a terrible disservice to the critics: there's lots of
hot air in the article but little devoted to the meat of the critics
complaints. Meanwhile, Linus' simple rebuttal is given full time, and seems
completely reasonable. It wasn't until I read this post that I felt that the
Linux maintainers may be doing some things wrong.

------
pjf
> The industry is entirely broken in terms of what it values.

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.

~~~
fulafel
I think Google has understood the systemic security problems in Android pretty
well since the beginning, but adopted a typical data driven approach: gather
data, and when/if phones start getting compromised start figuring out what
countermeasures are cost effective.

~~~
mtanski
I wouldn't agree with the statement. The Android app store is filled with apps
that steal user data and malicious apps. It only get cleaned up when somebody
does some research and tracks things down and it ends up in the press.

Or maybe that it's just cost effective to have others do the work for you?

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

~~~
nickpsecurity
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](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.

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

Popularity in distros would put a lot of pressure on the mainline kernel and
might get things moving there.

~~~
hga
Alpine Linux ships it, and while they're not a major distro, I get the
impression they're not "insignificant".

------
jakeogh
The Gentoo Hardened Project makes using grsec/PaX relatively easy.
[https://wiki.gentoo.org/wiki/Project:Hardened](https://wiki.gentoo.org/wiki/Project:Hardened)

~~~
meirelles
I used to be a security freak guy. Using the Gentoo Hardened, GRSecurity
PaX/RBAC, customized ACLs, etc. IMHO is a high-quality piece of software, very
polished and well-designed... I'm a Ubuntu guy today. For my small business,
such level of security is too much time consuming, drawing me back. It's kinda
sad.

~~~
hannob
You know, that's the problem. There is basically no reason why this is so
hard. Many security features could just be enabled by default by major
distributions with hardly any downside. You don't even have to look at
grsecurity. Just using pie binaries to enable proper ASLR would be a start.

~~~
rlpb
Ubuntu already does quite a bit:
[https://wiki.ubuntu.com/Security/Features](https://wiki.ubuntu.com/Security/Features)

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.

------
heinrich5991
See also this story:
[https://grsecurity.net/announce.php](https://grsecurity.net/announce.php).

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

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

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

~~~
nickpsecurity
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...](https://www.schneier.com/blog/archives/2014/04/dan_geer_on_hea.html)

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

------
zby
That looks like a political problem. Maybe the state should fund security for
its citizens - maybe we need some new kind of institutions to do this.

~~~
akerro
Currently states is looking for a way to legally hack into your phone,
computer, tablets, intercept all kind of communication and read offline data
without warrant. It's not how that works nowadays.

~~~
zby
They do that because nobody demands that they don't.

------
antocv
Well there is no Linux security.

L4 provides that.

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

------
digi_owl
Mother of all pissing matches...

