Why improving kernel security is important
mjg59.dreamwidth.org
mjg59.dreamwidth.org
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.
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.
(Remember, both SELinux and AppArmor are secondary defenses, not primary defenses; they potentially limit the damage if your system is already partially compromised.)
In part this is because at least SELinux only really works easily if you put everything in what the distribution considers its standard location and run things in the standard way. The moment you deviate from this, you wind up having to research an increasingly large number of file and executable contexts and (re)label an increasingly large number of files. And I'm ignoring NFS here, which we use heavily (I doubt NFS files can easily have SELinux attributes, especially when they live on non-Linux NFS servers).
Security is always ultimately about pragmatics. You have X amount of time to spend on security in all its aspects, and you need to use this time efficiently, to gain as much security from it as possible. Our judgement is that use of our security time configuring SELinux does not have a particularly high payoff.
(For clarity: I'm the author of the entry that mwcampbell linked to.)
I understand the pressure of not having enough time to do things perfectly. But the kernel is a project with widespread use in many domains, and the security features it implements have to provide strong security. We can't let kernel security requirements be dictated by environments that don't believe they require them. It's possible to set up a much less restrictive SELinux environment if you don't need or want to get the full benefit.
This also comes in to my first point, which is that we really need a better abstraction for SELinux configuration. Something that would be simpler to administer for environments that don't require the utmost in security isolation. But it should build on the strong in-kernel MAC implementation that already exists.
(At this point the OpenBSD pledge() work is looking attractive, although there are real organizational issues that would make it hard to do in Linux.)
Perhaps one can get to a better future with SELinux by having people build and ship systems for doing little SELinux configurations for daemons or systems that read daemon configuration files so they can automatically label directories and files for your system, or any number of other user friendly ideas. But we've had something like a decade of SELinux and its usability problems at this point and it hasn't happened yet. It's hard to avoid the obvious collection of conclusions.
NSA had had several multi-level secure operating systems developed for them in the past, but they didn't have any applications other than ones specifically written for them. SELinux was intended to remedy that.
Unfortunately, nobody seemed to understand that, and NSA doesn't do much outreach.
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.
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.
Having a visual interface to plug/sort sound inputs and outputs seems trivial, until you see someone running their skype conversation through FL Studio (in Wine!) to distort their voice using autotune, and then back out to the inputs. Or recording vocals over skype, filter with reverb, and sending them back over skype to the singer. in realtime. this stuff is _trivial_ in KXstudio.
Pulseaudio is still struggling with "Front Left", and "Front Right" both playing audio whilst getting in a fistfight with alsa. in 2015.
I'm building a (private) linux distribution for my corporations' chromebooks, based on gentoo/calculate KDE. I plan to avoid everything lennart poettering has touched. It'll be simultaneously vindicating and frustrating how my users will be saying "wow. you can do that in linux?" again.
(Many of the grsecurity changes are kernel hardening, for instance; they don't directly affect user level code.)
Don't forget Tomoy - I always thought the interface/ux at least (the side facing the sys.admin) looked much more sane than SELinux: http://tomoyo.osdn.jp/
That said, I'm not sure how much adoption Tomyo has seen, and an untested security measure isn't really great either.
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.
Kernel security is inevitably going to improve - the argument is over the length of time that's going to end up taking. If we continue to rely on the incompetence of those standing against us, we not only weaken those who don't have the knowledge or expertise to take advantage of their freedoms (and who end up with phones that are compromised by even more overtly evil actors than the phone vendors themselves), we eventually end up in a situation where the holes are blocked off and we have no method to achieve freedom at all.
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.
1. The vast majority of Android users don't know or care about it. They use what's on the device when they get it and if anyone's getting root, it's more likely to be a malware author than the user.
2. If the manufacturer locks you out, the benefit from a root exploit is time-limited until they ship an update and you're faced with losing root or having known security problems.
3. Using root when the manufacturer doesn't want you to is likely to be used as an excuse to deny support requests later.
It's not helpful to anyone to suggest a computing experience which can change at any time and requires them to delay things like security updates until a new exploit can be found. #1 and #3 combine, in that people are either going to avoid using an exploit if it could mean eating the cost of a new phone at any time or, worse, their buddy will do it for them but not help with the ongoing sysadmin work needed to keep the rooted phone secure. It's worth remembering that the only iPhone users at risk of the Hacking Team exploits were the ones who'd jailbroken the device; I'd bet anyone affected reconsidered how much installing ad blocker or pirated game was really worth.
If you want root, the only viable solution is to refuse to give money to vendors which don't let you have it, which currently means contacting your government to express your support for legal restrictions on devices which cannot be customized by the user. If you continue to support restrictive vendors with your wallet, absolutely nothing will change.
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.
Besides, if free software can't provide security, people won't run free software. End of story.
I don't understand: Nexus products don't ship with root access for users, and while users can obtain root access through various methods, they can do the same on almost any mobile device. They can also replace Android with various alternatives on almost any mobile device. How are Nexus products special in these regards?
$ fastboot oem unlock
On the vast majority of other Android phones, one must perform a customized attack against your phone in order to unlock the bootloader... and on some phones, that attack has not yet been discovered.
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)
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.
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.
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 ) 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.
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/
Most aren't remotely exploitable (most of those that are in recent memory are SCTP-related), but they're serious nonetheless.
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.
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.
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.
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.
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.
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.
No - one of the primary mechanisms attackers use to gain root is to exploit kernel vulnerabilities.
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.
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.
http://www.openbsd.org/papers/hackfest2015-pledge/mgp00003.h...
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.
He did call the OpenBSD folks that: http://article.gmane.org/gmane.linux.kernel/706950
Well, I guess he had that one coming, then. Forget everything I said :)
[1]: http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.h...