
Why improving kernel security is important - luu
https://mjg59.dreamwidth.org/38158.html
======
mwcampbell
Perhaps the promotion of SELinux and its integration in some major distros is
impeding the adoption of more practical kernel security measures like AppArmor
or grsecurity. At least that's what Chris Siebenmann, a long-time sysadmin for
the University of Toronto's CS department, thinks.

[https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxWhyICa...](https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxWhyICare)

What I don't like about SELinux is that it doesn't integrate easily with
existing tools. It requires special filesystem attributes, and tools like ls
and cp have to be modified to support it. Third-party tools like Ansible also
have to go out of their way to support SELinux. It seems to me that AppArmor
and grsecurity don't have that problem nearly as much.

~~~
throwaway7767
I feel like what SELinux is missing is an extra layer of abstraction for the
configuration, to make it easier for humans to work with.

The "Just disable SELinux!" sysadmin answer strikes me as coming from the same
place as "Just disable IPv6!" and "Just disable PulseAudio!" \- a lot of
sysadmins don't like having to learn new things. I've done sysadmin work for
about 20 years now, and I don't share that view - learning new things is a
necessity in this line of work. You either learn a new thing you can apply in
your work, or you find out it's not a good solution and now you have an
informed opinion on why it's not good.

You mention AppArmor as a "more practical security measure" being held back by
SELinux. But Chris's blog post states that they disable that too. In essence,
his argument seems to be "I don't really care about all this security stuff, I
just want it to work the same way it always has". I understand the viewpoint,
but that's not the way to progress.

~~~
striking
> PulseAudio

I abhor PulseAudio, because it just doesn't work as smoothly as JACK or ALSA.
Sometimes learning a new thing isn't necessary, as the old ways of doing
something still hold.

I agree with the BSD way of doing this: force it on the users and try and help
them come to terms with your changes. If there's a revolt and/or it's too much
work for you, revert. Otherwise your entire ecosystem is safer.

~~~
throwaway7767
In my experience, most of the problems people have with PulseAudio come down
to buggy ALSA drivers not handling buffer resizing correctly. Adding tsched=0
as a module option "fixes" that by making them not export the buggy
interfaces. The result is much the same as playing directly through ALSA.

The reason PulseAudio wants to use these interfaces is that it has to make a
tradeoff between CPU utilization+battery usage versus low latency. If you use
ALSA directly, the first application to open the device controls the size of
your buffer. The first client was a music player requesting a large buffer?
Then your SIP client will get high-latency audio. PulseAudio tries to fix this
by dynamically resizing the buffer.

I'm sure there's actual issues with PulseAudio, but somehow most of the
problems I see people complain about lie further down the stack.

Of course, discussion of pulseaudio is rather off-topic here, it was just one
more example of how "just shut down the new thing!" is often easier than
diagnosing the actual problem.

------
kragen
Currently, most users of computers running Linux own those computers, but do
not have root access to those computers, because they are cellphones running
Android. Instead, Samsung, Google, HTC, and random human rights abusers like
Hacking Team have root access to them. Those users can currently obtain root
access to their own computers only because of vulnerabilities in the kernels,
hardware, and occasionally applications being used.

Given this very bad situation, I would argue that improving kernel security is
at best ambiguously beneficial and possibly actively harmful to users. Maybe
we should wait to improve kernel security — probably by switching to a
different kernel — until we have somehow managed to escape this very dangerous
situation in which people do not have root on their own computers.

~~~
acdha
This is a pointless philosophical debate: leaving kernel bugs unfixed will not
make Android a more open platform. That problem needs to be fixed at the
vendor level but there's no reason to make the rest of the Linux-using world
less secure while waiting for that to happen, to say nothing of the likely
much greater number of Android users who will see those exploits used by
malware.

~~~
kragen
This is as far from a pointless philosophical debate as it could possibly be.
We are discussing whether people should be able, _in practice_ , to get root
on their own phones. Leaving kernel bugs unfixed is the way that happens
today. When people get root on their phones, they can then uninstall the
malware _that is already installed on the phone when they buy it_.

At this point, Android user-owners are the vast majority of the Linux-using
world, and indeed the computer-using world. Their needs and interests would
outweigh those of everyone else if they were actually in opposition.

~~~
tremon
It is philosophically pointless, as you are arguing from an untenable
position: if you don't trust your system provider, you shouldn't trust your
system. Leaving kernel bugs unfixed does not make your system any more
trustworthy.

From a practical point of view, it's a different matter: the exploits may
allow you to regain some control over an untrusted device. But you still have
the fundamental disparity of you trying to gain (software) control over an
untrusted (hardware) device. That makes it a pointless philosophical debate
regardless of practical use.

~~~
kragen
Oh, I hadn't thought of that interpretation of "pointless philosophical
debate". You're right: considered as a purely philosophical debate, it's
pointless. But considered as a debate over what practical measures to improve
our contingent human reality in the face of non-ideal and poorly understood
circumstances, it's far from pointless.

------
csvan
"The number of people using Linux systems is increasing every day, and many of
these users depend on the security of these systems in critical ways. It's
vital that we do what we can to avoid their trust being misplaced."

This, a thousand times over. Security and privacy concerns are ultimately
among the make-or-break points of any major platform, and Linux needs to pass
this with flying colors, especially as it grows ever closer to the ordinary
user who is finally considering replacing Windows.

~~~
mtgx
Even without the point about more users wanting to replace Windows with a
Linux distro, it makes harder to argue that "ATMs should run Linux instead of
Windows", if Linux is falling behind in security. Also, ATMs should probably
run OpenBSD.

~~~
dfox
Mainly, the PC inside ATM should not do anything remotely security critical.
PC-based ATM platforms are actually designed around compartmentalization and
in ideal case the PC should only draw UI on screen, handle some subset of
input events and route encrypted messages between other components of the ATM
(whether it's implemented in this way in actual deployments is another issue).

------
dankohn1
You can follow some of the security work the kernel community is doing via the
kernel hardening mailing list:
[https://lwn.net/Articles/663361/](https://lwn.net/Articles/663361/)

------
msl09
> So they took advantage of the fact that many Android devices shipped a
> kernel with a flawed copy_from_user() implementation that allowed them to
> copy arbitrary userspace data over arbitrary kernel code, thus allowing them
> to disable SELinux.

If the problem was on the flawed copy_from_user() so why is he talking about
improving the kernel the manufacturer was at fault for tampering with the
safety?

>If we could trust userspace applications, we wouldn't need SELinux.

I won't argue that SELinux is a bad solution to our security problems and that
a cleaner kernel-native solution would be better. But the very fact that we
are still having
this([https://news.ycombinator.com/item?id=10537268](https://news.ycombinator.com/item?id=10537268)
) discussion shows that we haven't yet agreed upon a definite solutions for
the code isolation problem. Docker container model is definitely a much better
approach for limiting system calls, but is anyone seriously considering
integrating docker to the kernel source code?

Another problem is that, while may have a lot of proposals for the problems,
implementations(like Grsecurity) and even have a satisfactory number of
developers, we have only so many trusted reviewers to audit that code, so we
will always lose one or another.

Furthermore, I'd like to note that with neither shellshock nor heartbleed was
a kernel was the problem, in fact I don't even remember the last CVE related
to the kernel that I've seen. So is the kernel security as horrible as the
recent uproar seems to warrant?

Finally we need to be honest with our selves here. Most problems with security
that we face today are not directly related to the software that we run, it's
related to how e build, ship and evaluate our software. We don't have a
security focused mindset in the corporate world, security does not add to the
product value to the average user, so we end up shipping code with obvious
security flaws. As a tech savvy community we cannot just pretend that security
is everybody else's fault.

All that said I don't think we should turn a blind eye to the security
limitations of the kernel, but I don't think that the kind of narrow minded
discussion that have been floating around the problem will improve anything.

~~~
mrweasel
>So they took advantage of the fact that many Android devices shipped a kernel
with a flawed copy_from_user() implementation that allowed them to copy
arbitrary userspace data over arbitrary kernel code, thus allowing them to
disable SELinux.

Why is it even possible to disable SELinux at runtime? That should be a
compile time option. Either you want the added security, or you don't. It's
useless if someone can turn it off.

It required a flawed copy_from_user() implementation, which is now fixed.
That's just not the only bug in the Linux kernel, there will be new ones. New
ones that may or may not allow a attacker to disable SELinux. The problem is
that it is modifiable.

Earlier today there was the story about OpenBSDs pledge(). One of the basic
ideas of pledge is that you can't turn it off.

~~~
forgottenpass
_Why is it even possible to disable SELinux at runtime?_

Because policy configuration happens from userspace. And it doesn't really
matter if root users are disabling it, or just doing the equivalent of `chmod
-R 777 *` without technically "disabling" it.

~~~
jjuhl
No. Because bugs.

If you can write to arbitrary kernel memory you can do anything you like.
Disable selinux; write funny messages to the console - it's all yours for the
taking.

------
pnathan
Contrarian stance here: if kernel security is important, the game is over, the
attacker has root; they are running code on your server and you've lost
because of one of the innumerable issues that the attacker knows that you
don't. Restated, the kernel is defined to be insecure; now play the game. :-)

Design wise, the principle I've adopted is that each server is running an
application set; when one of those applications is compromised, the server is
_immediately_ rooted, game over, all applications in the set are compromised
and the attacker controls those resources and the server. In general, the
layer of security I am looking for to control server rooting is an
application's security, preceded by network level security. Separation of
security regions (domains, whatever you want to call them) is accomplished by
having different ephemeral servers; exploitation of one region not rachetable
to the next region unless it's prespecified that way.

~~~
mjg59
> If kernel security is important, the game is over, the attacker has root

No - one of the primary mechanisms attackers use to gain root is to exploit
kernel vulnerabilities.

~~~
pnathan
Right.... if you're relying on the kernel to protect you, you're dead in the
water as it is, today. So the reasonable defense is to _assume_ the kernel
security doesn't exist.

~~~
mjg59
The reasonable long-term defence is to improve kernel security.

~~~
pnathan
Honestly...no. I don't think so.Security is much too much of a cat and mouse
game at this level, where you're specifically fixing things to deal with
attacks. There will always be another vulnerability, another bad coding
practice that someone comes in through. It's not provably secure (it's in C
and has le five zillion config options; among other things); it's not secure
by design (wasn't designed for security); it's not even secure by effort
(Linus is not a religious fanatic about security).

So the sane approach until a fully redesigned system comes by is to assume
that it only provides a _thin_ layer in the defense game and partition access
levels and security controls appropriately.

~~~
mjg59
I don't want to sound overly hostile here, but have you actually read the
post? Many (if not most) kernel bugs _can_ be mitigated with existing
technology, and there's ongoing research that will bring this down even
further. There are certainly scenarios where assuming that any level of
compromise may be significantly deeper than you imagined is the correct
response, but that's not a supportable response in the majority of cases.

Looking at it another way - if application security is important, the game is
over, the attacker has already got in via the network. We're bad at writing
applications, so we shouldn't expose them to the internet.

~~~
AnimalMuppet
All of the above. Do the best you can at network security, and try to get
better. Do the best you can at application security, and try to get better. Do
the best you can at kernel security, and try to get better. And do the best
you can at intrusion detection, and try to get better.

------
jvdh
The name-calling referenced in this article also influenced a talk by Theo de
Raadt on a new security feature for OpenBSD:

[http://www.openbsd.org/papers/hackfest2015-pledge/mgp00003.h...](http://www.openbsd.org/papers/hackfest2015-pledge/mgp00003.html)

~~~
darklajid
What name calling? And how is that related?

~~~
striking
The image is of a plastic masturbating monkey, probably in reference to Linus
Torvalds. They call him "Loudmouth Linus" because he reportedly called them
names, and reference the recent WaPo article.

Look, honestly? What BSDs are doing is great for those who want to take
advantage of it. The mitigations they are adding will probably eventually be
merged into the Linux kernel. And if not, unless users stop using Linux, Linux
will exist without them.

And thus, I think this is an immature reaction to having a pull request
refused. This is many things, beginning with "not nice."

The BSDs have their own stuff, the Linux users have theirs. Dunno what the
hubbub is about.

~~~
protomyth
> They call him "Loudmouth Linus" because he reportedly called them names, and
> reference the recent WaPo article.

He did call the OpenBSD folks that:
[http://article.gmane.org/gmane.linux.kernel/706950](http://article.gmane.org/gmane.linux.kernel/706950)

~~~
striking
Huh. Masturbating monkeys.

Well, I guess he had that one coming, then. Forget everything I said :)

