7 ms·

Why improving kernel security is important

146 points by luu 11y ago

csvan 11y ago
"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 11y ago
  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 11y ago
    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).
mwcampbell 11y ago
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/SELinuxWhyICare https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxWhyICa... 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 11y ago
  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 11y ago
    > 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 11y ago
      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.
jvdh 11y ago
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.html http://www.openbsd.org/papers/hackfest2015-pledge/mgp00003.h...
- darklajid 11y ago
  What name calling? And how is that related?
  - striking 11y ago
    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 11y ago
      > 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 11y ago
        Huh. Masturbating monkeys. Well, I guess he had that one coming, then. Forget everything I said :)
  - fao_ 11y ago
    I think the poster perhaps meant to link to the presentation generally[1], which goes over the introduction of BSD's pledge() feature[2]. [1]: http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.html http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.h...
kragen 11y ago
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.
- maxerickson 11y ago
  The choice between Google and Hacking Team seems super easy to me. I also wonder if making root more available ends up enabling the bad actor at the phone store more than it ends up helping end users. (I do get that many people see it as an matter of principle)
  - kragen 11y ago
    It's not a choice between Google on one hand and Hacking Team on the other. It's a choice between Google and probably Hacking Team, on one hand, and the user, whoever they decide to trust to help them root their phone (the actor at the phone store, who may be good or bad), and probably Hacking Team anyway on the other.
    - maxerickson 11y ago
      I meant someone at the phone store intervening without the user's knowledge. Improving user control without also enabling that tampering is a challenge. I will insist that there is a large group of users that will do exactly what the employee of the phone store tells them to do, even if it is easy to discover that this is a bad idea. I also didn't thoughtlessly make that first point. Fixing 100 bugs does not have zero impact on whether Google or Hacking Team ends up with control.
msl09 11y ago
> 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.
- throwaway7767 11y ago
  > 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? The flawed copy_from_user came from the upstream linux kernel. The malware vendor just took advantage of the security bug which the vendor had not patched. Proper SELinux rules could have prevented this from being exploited. > 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? Do you follow any of the bug disclosure lists? Kernel security issues are common. If your primary source for security vulnerability news is mainstream media, you should be aware that that's a horrible way to stay informed. Most bugs do not get a catchy name like "ShellShock" or "BEAST", they just get a nondescript CVE number and are patched. Media coverage is a terrible indicator of severity of security bugs. Just as an example, search for "linux" on this page. This is not a complete list, I'm sure there's better resources but I didn't have time to find them. https://www.debian.org/security/2015/ https://www.debian.org/security/2015/ Most aren't remotely exploitable (most of those that are in recent memory are SCTP-related), but they're serious nonetheless.
dankohn1 11y ago
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/
pnathan 11y ago
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 11y ago
  > 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 11y ago
    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 11y ago
      The reasonable long-term defence is to improve kernel security.
      - pnathan 11y ago
        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.

146 points by luu 11y ago

csvan 11y ago

"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 11y ago
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 11y ago
  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).

mwcampbell 11y ago

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/SELinuxWhyICare https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxWhyICa... 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 11y ago
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 11y ago
  > 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 11y ago
    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.

jvdh 11y ago

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.html http://www.openbsd.org/papers/hackfest2015-pledge/mgp00003.h...

darklajid 11y ago
What name calling? And how is that related?
- striking 11y ago
  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 11y ago
    > 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 11y ago
      Huh. Masturbating monkeys. Well, I guess he had that one coming, then. Forget everything I said :)
- fao_ 11y ago
  I think the poster perhaps meant to link to the presentation generally[1], which goes over the introduction of BSD's pledge() feature[2]. [1]: http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.html http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.h...

kragen 11y ago

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.

maxerickson 11y ago
The choice between Google and Hacking Team seems super easy to me. I also wonder if making root more available ends up enabling the bad actor at the phone store more than it ends up helping end users. (I do get that many people see it as an matter of principle)
- kragen 11y ago
  It's not a choice between Google on one hand and Hacking Team on the other. It's a choice between Google and probably Hacking Team, on one hand, and the user, whoever they decide to trust to help them root their phone (the actor at the phone store, who may be good or bad), and probably Hacking Team anyway on the other.
  - maxerickson 11y ago
    I meant someone at the phone store intervening without the user's knowledge. Improving user control without also enabling that tampering is a challenge. I will insist that there is a large group of users that will do exactly what the employee of the phone store tells them to do, even if it is easy to discover that this is a bad idea. I also didn't thoughtlessly make that first point. Fixing 100 bugs does not have zero impact on whether Google or Hacking Team ends up with control.

msl09 11y ago

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

throwaway7767 11y ago
> 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? The flawed copy_from_user came from the upstream linux kernel. The malware vendor just took advantage of the security bug which the vendor had not patched. Proper SELinux rules could have prevented this from being exploited. > 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? Do you follow any of the bug disclosure lists? Kernel security issues are common. If your primary source for security vulnerability news is mainstream media, you should be aware that that's a horrible way to stay informed. Most bugs do not get a catchy name like "ShellShock" or "BEAST", they just get a nondescript CVE number and are patched. Media coverage is a terrible indicator of severity of security bugs. Just as an example, search for "linux" on this page. This is not a complete list, I'm sure there's better resources but I didn't have time to find them. https://www.debian.org/security/2015/ https://www.debian.org/security/2015/ Most aren't remotely exploitable (most of those that are in recent memory are SCTP-related), but they're serious nonetheless.

dankohn1 11y ago

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/

pnathan 11y ago

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 11y ago
> 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 11y ago
  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 11y ago
    The reasonable long-term defence is to improve kernel security.
    - pnathan 11y ago
      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.