
Unsafe at any clock speed: Linux kernel security needs a rethink - guardian5x
http://arstechnica.com/security/2016/09/linux-kernel-security-needs-fixing/
======
tytso
This effort to harden the Linux kernel is not new. Kees made a very similar
presentation at the Kernel Summit last year[1] and it was quite well received.
After his presentation, the kernel-hardening mailing list was revived, and new
features to add additional hardening to the kernel has been rolling into Linux
for the last couple of releases.

There are engineers from multiple vendors collaborating on this project, and
they have been using the kernel-hardening list for traffic control and for an
initial review of the patches before asking that they be pulled. The progress
section of this LWN article[3] shows that they've been quite successful so far
--- or perhaps, it would be more accurate to say they've made a good start.

    
    
      [1] https://lwn.net/Articles/662219/
      [2] http://www.openwall.com/lists/kernel-hardening/
      [3] https://lwn.net/Articles/698827/

------
tux1968
Here is Kees Cook talk from the Linux Security Summit, "The State of Kernel
Self Protection Project", he makes the same analogy to car safety in his talk:

[https://www.youtube.com/watch?v=aMkCKeZ8xZw](https://www.youtube.com/watch?v=aMkCKeZ8xZw)

All the available videos from the Linux Security Summit are listed here:

[https://www.linux.com/news/linux-security-summit-
videos](https://www.linux.com/news/linux-security-summit-videos)

~~~
Animats
It's _not_ like car safety. There's an enemy. The enemy is not random.

Patch and release only works against inept opponents, and there are more non-
inept opponents. It won't work against opponents who can develop or buy their
own exploits. Patch and release gives the illusion of working because it stops
vast numbers of inept attacks from clowns who just want to send spam emails.

Someone in military base security once said that you have to avoid tying up
too much of your resources chasing kids throwing rocks at the perimeter fence.
The real threat is the janitor who has access to the spare parts stores. Patch
and release, and pattern-matching virus scanners, are chasing kids throwing
rocks.

~~~
tux1968
You're making his point for him.

His point is that cars used to be built assuming there would never be an
accident. They were very comfortable until you crashed into something, and
then everyone died. Today cars are built defensively, so that when the
unforeseen happens, you are still protected.

That's the idea. Building in defenses that protect you against unknown bugs
and exploits.

~~~
tedunangst
But cars still only offer protection against mostly random events, not
determined adversaries rail gunning projectiles through the wind shield.

~~~
eximius
There should be some limit to the threat model, though. It should not attempt
to remain secure when something can do arbitrary read and writes (VM), for
example. Even determined adversaries will merely be armed, not equipped with
WMDs.

------
sqeaky
The article was surprisingly light on details. They didn't mention specific
fixes or techniques they wanted to move upstream. They also didn't mention why
they thought Linux was architected to be unfriendly for end users. Ubuntu,
Mint and Android are way easier to use than windows for example, or do they
think that the kernel needs to do something special for an end user that will
never see it?

I am not saying they are wrong, but they didn't give me much reason to believe
they are right.

~~~
helthanatos
I don't really see ease of use differences between any polished OS besides
OSX, which is just because finder is odd. Maybe they think the terminal is too
powerful?

~~~
Locke1689
You're both missing the point. They're talking about kernel security -- when
they refer to "usability" they mean compatibility and ease of programming for
user-mode applications interfacing with the kernel ABI.

This has nothing to do with non-programmers.

~~~
sqeaky
They are the ones who brought up non-programmers and that is why I accused
them of being light on details.

I agree that point is preposterous, but it is their point.

------
jbangert
A lot of research has been made in this direction by the PaX team/brad spender
of grsecurity. In fact, many of these techniques were first implemented on
modern kernels by that bunch. However, political moves have always clouded
that -- pax/grsec is run as a project of passion and not as a day job, and
therefore there has always been reluctance to deal with those (and get
involved in sometimes very territorial code review/maintenance sessions).

Unfortunately, by not really crediting or even acknowledging this research
(and also ignoring a lot of work thats been happening in academia on hardening
commodity kernels and applications), the Linux kernel is a)playing catch up to
other operating systems (instead of adapting newer techniques) and b)
alienating researchers even further.

~~~
ploxiln
grsecurity offers commercial support, and customer-only stable updates. (Only
the latest version of the patchset for the latest linux kernel is available at
no cost.) (Of course, if you pay and receive a stable update, you can re-
distribute it under the terms of the GPLv2.) grsecurity is not a hobby.

A lot of their work has not been accepted into the mainline linux kernel ...
but it's hard for me to see how this is a problematic sort of "not really
crediting or even acknowledging". If anything, it pushes people to go to the
source, grsecurity itself, for their "hardened" kernels. It seems that
grsec/pax do have a lot of recognition as a result.

Yes, the inventors and developers of these hardening techniques want to be
praised and have their work immediately used as-is to save the world. But we
don't all have to want the same thing, to have the same priorities. We don't
all face the same threats, nor performance and feature requirements. If people
want to make the various trade-offs in favor of a significantly more
"hardened" kernel, they've been free to use grsecurity or openbsd for quite a
while. No need to blame linux-mainline maintainers for the people who have not
made that choice. There's really no unfair lock-in going on here...

~~~
AstralStorm
Grsecurity and Pax are ineffective against almost all kernel bugs. They only
make a small set of bugs (relying on suitable code) harder to exploit.

Those measures are meant to protect user space, not the kernel.

------
pmontra
See this other post
[https://news.ycombinator.com/item?id=12595936](https://news.ycombinator.com/item?id=12595936)
about a botnet of 150k cameras and DVRs which is DoSing OVH at 1 TB/s. Chances
are that they run on Linux. The exploit could be as simple as telnetting to
them with a default password, but more sophisticated attacks could exploit old
kernels left unpatched forever. Actually, some devices might be impossible to
patch, as much as you can't make that Chevy from '59 any safer. You have to
buy a new one.

------
grizzles
Besides a bit of lip service to code correctness, what can they do really?

They aren't going to move the kernel to a microkernel type design and besides,
using advanced hardware features is out, because that would too closely tie
the kernel to a single architecture. You could argue there is a business case
for Intel and ARM to produce hardened Linux forks for their respective
architectures as a form of competitive advantage, but since it hasn't happened
in the past, I wouldn't be optimistic.

Also historical precedent has shown they aren't going to get tough on the
vendor drivers. The kernel is filled with binary blobs (mostly firmwares), and
as the article points out, vendor drivers are where the lion's share of the
bugs are coming from.

~~~
Locke1689
> They aren't going to move the kernel to a microkernel type design

Food for thought: the Windows Subsystem for Linux proves that it's possible to
implement the Linux kernel ABI without actually _being_ Linux.

I'm not sure how far you could go re-implementing the ABI on top of a
microkernel architecture.

~~~
smitherfield
And the BSDs have implemented the Linux ABI for years.

------
sirwitti
To me this article sounds more like political propaganda than talking about
real issues. Correct me if I'm wrong, but I didn't read any explanation of why
the author think linux has huge security issues (whether or not that is true
is a different matter).

Unless there is any substantial claim, articles like these are bullshit to me.

~~~
Arnt
You didn't read, but the (original) author did write.

One of the problems (already solved now) was that the kernel had unlimited
access to userspace, ie. once you've found a kernel bug that permits the
kernel to do something wrong involving user-supplied arguments, you could
prepare data/code and then use the bug to make the kernel read or act on your
prepared data. Now that most kernel code is blocked from reading most
userspace, you have less ability to direct the kernel's behaviour when you
want to exploit a bug.

There's more. It's good stuff.

~~~
paulddraper
Eh. A compromised kernel can do all sorts of bad stuff... Which brings us bad
to the question: do we have substantive reasons to think it's vulnerable?

~~~
Arnt
Yes, that's a question. We can safely assume that it's buggy, though, since
most/all prior kernel versions have had bugs of one sort or another. That
assumption doesn't depend on the question you raise.

Given that it's buggy and that linux is widely used, we can also safely assume
that someone will try to exploit the bugs, which makes it sensible to limit
the likely possible consequences of bug. Or put differently, to minimise the
risk that a bug is a vulnerability.

------
FussyZeus
As important as security is, and as much as I think Linux should be secured
more proactively, I have to take issue with two things mentioned:

1\. Most devices are not administered by IT Professionals

This is true and must be taken into consideration, but while every layman
can't be a sysadmin, neither can you, I think in 2016, simply take a position
of "I don't need to understand any of this, and everything should Just Work."
I don't think that's realistic, if you want the home automation we see in the
Jetsons, if you want smart devices in your home setup to make your coffee at
exactly 5:56 AM, then you need to step up and take a little responsibility for
learning how this stuff works and how to set it up. Now is it realistic for
end users to perform kernel updates, testing functionality, and changing out
for new packages as needed? Of course not. But a basic understanding of the
underlying technology helps in a long way in troubleshooting the inevitable
problems that will arise, and in letting you choose, intelligently, what OEM's
to do business with.

2\. Manufacturers leaving devices un-updated, unmaintained after production

This is asinine, especially for the devices that require online connectivity.
You already have a more-or-less constant WAN connection, so why on Earth can't
these devices update their firmware when required? The answer is of course
that after-sale support is not profitable but that too is unacceptable, if
you're going to bake computers into your products, you as a company need to
step the hell up and support them, not just throw them on the market for a
quick buck and then run away with the cash.

My 0.02.

~~~
drvdevd
Android is probably a good example of the update problem in action, but it's
hard to blame Linux directly for this. Rather it is indeed the product cycle
that seems to be driving the problem as you point out in #2 there. But then
again, isn't it reasonable to expect _some_ sort of deprecation or end of life
for most products?

Also, even if manufacturers are held to account more, we will still see severe
bugs, IMO, in Linux or even some hypothetically more secure, future OS.

As it's framed in this article at least, I think the automotive manufacturer
metaphor falls down at some point (even if most cars now run Linux too). I
think software is just vastly more complex and we are just now learning how to
cope with that complexity.

~~~
pjmlp
> I think software is just vastly more complex and we are just now learning
> how to cope with that complexity.

If an engineer builds a bridge and it falls down, s/he will get punished for
it.

If a doctor or a lawyer makes a similar hard mistake, s/he will get punished
for it.

The same needs to happen to software engineering, specially given that in most
countries software engineering is a degree with the respective Engineering
Order.

~~~
drvdevd
I agree that liability has its' place in software engineering. But I don't
think, at this point in history at least, we can apply it broadly across the
many subdomains thereof.

For example, we can't hold Linus Torvalds liable when the Linux Kernel has a
bug (perhaps not even if it was deliberate!). If we even tried to, the entire
project would likely come to a screeching halt.

How is this model of liability compatible with large open source codebases?

~~~
ex_amazon_sde
> How is this model of liability compatible with large open source codebases?

Yes, like in other fields. Obviously people are not chased out of town for as
small error.

It's when people conspire together to hide big problems that liability becomes
important.

~~~
drvdevd
Agreed. Which, as evidenced by the recent emissions scandals, is a quite
realistic scenario.

------
zamalek
It's a pity that the easiest solution we have for this security problem
(managed languages[1]) is also at odds with the environment: real-time. Maybe
a Rust operating system designed for real-time could help here.

[1]:
[https://en.wikipedia.org/wiki/Midori_(operating_system)](https://en.wikipedia.org/wiki/Midori_\(operating_system\))

~~~
pjmlp
Personally I think it is at odds with political wishes to do so, not
technical.

If there is political support, the research will eventually produce the
desired results.

We already had such managed environments in the 60's and 70's, those
researchers and companies would be in heaven if they could even have a
Raspberry PI like hardware at their disposal.

------
cobbzilla
I agree that the article was very light on details.

I like the philosophy of trying to squash whole classes of bugs and generally
trying to reduce the attack surface, versus one-by-one bugfixes.

I am curious about the solutions the Linux developer community will come up
with to address this. There are many, many _very_ smart developers and I look
forward to some creativity :)

I am optimistically hopeful that proposed solutions will not involve anything
resembling a central authority that must be trusted -- something based on
Certificate Authorities (or any analog to Microsoft's Trusted Computing
model), would be really disappointing.

~~~
jessaustin
_I am optimistically hopeful that proposed solutions will not involve anything
resembling a central authority that must be trusted_

ISTM that _most_ distros use central software repositories, already? And that
is very much a good thing? Definitely anything run by M$ or a similar firm
could have conflicting goals, but don't paint e.g. the Debian Project with the
same brush.

~~~
cobbzilla
I wasn't painting with any brushes, just expressing optimism and hope for a
good solution.

Any Linux user is free to use whatever distro they want. Once you've chosen a
flavor of Linux, in theory you could even run your own apt/rpm repository.
There is no requirement that a Linux user _must_ trust some third-party or
their system won't run. Let's keep it that way :)

~~~
jessaustin
Good point! One could imagine a really big customer forcing M$ to let it use a
company repo, but that option would rarely be offered to consumers.

------
TwoBit
How does this compare to the state of the Windows kernel? Serious question.

~~~
pjmlp
Microsoft has made serious efforts to push the driver stack up to user space,
since Windows Vista.

They use a theorem prover to validate drivers.

Static analysis is a enforced on the Windows source code via the Security
Development Lifecycle Checks.

VC++ has quite a few security options that are enabled and used to compile the
kernel.

After the whole Windows XP Swiss cheese episodes they ramped up quite a few
security processes.

Windows 10 allows for individual application sandboxing.

~~~
AstralStorm
Time to return to that old chestnut of a microkernel vs monolithic kernel
debate?

~~~
pjmlp
Microkernels have won, just the GNU/Linux community seems be unaware of it and
keep repeating the words of the leader.

Not only we have millions of embedded devices shipping microkernel OSes on
them, we also have the transition to type-1 hypervisors, and now the slow
adoption of unikernels.

Also Apple, Microsoft and Google are increasing the scope of sandboxing on
their OSes.

------
KaiserPro
For IoT its not the kernel that's at fault, its the weak passwords, telnet,
and non-unqiue default username and passwords.

Its astoundingly rare to get owned purely by a kernel exploit. Yes they are
used, but _mostly_ when initial access has been obtained.

~~~
caf
Frequently the kernel is moot because the buggy userspace stuff is all running
as root anyhow.

------
the_duke
Very light on details...

So what can actually be done to harden the Linux kernel?

------
eugeneionesco
You can't this seriously since it does not mention grsecurity.

No need to "rethink" kernel security, just use grsecurity.

~~~
viraptor
They do mention it, just not by name. Kees Cook and the Kernel Self Protection
Project is basically trying to move some protections that exist in grsec into
mainline kernel. (since grsec as a whole will never get accepted)

~~~
micaksica
And a 2009 LWN post as to why grsec won't be accepted:
[https://lwn.net/Articles/313621/](https://lwn.net/Articles/313621/)

------
eeZah7Ux
"Killing bug classes, not political dissidents"

...what a very poor choice of words.

------
revelation
Hilarious, Android developers telling other people their software is unsafe.

The most dangerous software is one you can never update. Android leads the
tivoization of devices globally.

~~~
xbmcuser
They update android but understand the problem Linux faces as manufacturers
and carriers don't update the android devices. Many android vulnerabilities
come through because of the Linux stack so fixing that would fix a good
portion of Android future vulnerabilities

~~~
jkot
Most bugs in Android 4.4 are not fixed. That is just three years old branch.
Upgrading to latest 7.x is not an option for everyone

Linux has LTS support for 15 years. WinXP was supported for 13 years.

------
VarFarYonder
God damn it. Titor was right.

------
walter_bishop
“For the cases where computers are not well protected in the hands of end-
users who are not IT professionals, and who do not have any recourse to IT
professional help, we need to design systems that proactively protect them”,
Konstantin Ryabitsev of the Linux Foundation

Is this the same Linux Foundation that gave Microsoft Keynote Position at the
last LinuxCon?

