4 ms·

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

by 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.
mrweasel 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. 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 11y ago
  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 11y ago
    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.
- tremon 11y ago
  > Why is it even possible to disable SELinux at runtime? As with all things SELinux, it's a policy setting. You can configure your policy to disallow disabling SELinux. That wouldn't have made a difference in this case though, when you have unprivileged applications accessing kernel memory directly.
- mjg59 11y ago
  > Why is it even possible to disable SELinux at runtime? If you're able to overwrite arbitrary kernel memory you can just replace the SELinux code with code that says you can do anything. The idea is to make it more difficult to take advantage of kernel bugs such that you can modify arbitrary kernel state.

by msl09 11y ago

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.

mrweasel 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. 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 11y ago
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 11y ago
  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.
tremon 11y ago
> Why is it even possible to disable SELinux at runtime? As with all things SELinux, it's a policy setting. You can configure your policy to disallow disabling SELinux. That wouldn't have made a difference in this case though, when you have unprivileged applications accessing kernel memory directly.
mjg59 11y ago
> Why is it even possible to disable SELinux at runtime? If you're able to overwrite arbitrary kernel memory you can just replace the SELinux code with code that says you can do anything. The idea is to make it more difficult to take advantage of kernel bugs such that you can modify arbitrary kernel state.