The Truth about Linux 4.6
forums.grsecurity.net
forums.grsecurity.net
http://www.theregister.co.uk/2016/04/27/linux_security_bug_r...
I don't know who's right or wrong, but I wish Linux people (both sides) behaved more civilly. Linus breeds an atmosphere where personal attacks and insults are encouraged in the name of supposedly better code.
And on topic: Why can't the grsecurity patches just be merged into the kernel?
grsecurity has done a huge amount of innovation in kernel security, and they deserve quite a bit of credit for that. But grsecurity made a very public and vocal decision to no longer attempt to get any of that work into the upstream kernel, because they don't enjoy having to deal with the process involved in collaborative development. Instead, they went off and built a company around their out-of-tree work, and try to advocate that people use it.
Meanwhile, some of the ideas that grsecurity pioneered (and a lot of other security innovations from other sources too) have started to make their way into the kernel, championed by people who are willing to do the work and participate in a collaborative development process. And the repeated response from grsecurity involves public whining, bashing of people doing the work they refuse to do, and, of course, advertisement.
Whining that Linux doesn't have the security technology that they do seems rather hollow coming from people who very vocally gave up on doing the work to actually make Linux better. Out-of-tree, out-of-sight, out-of-mind.
I don't think that's fair to say. grsec provides many things. Some are completely transparent once implemented, (readonly variables) some have performance impact, (uderef on 32bit) some (purposely) break existing behaviour. (forbidden MSR writes prevent energy management)
You can pick and choose what you want. In practice on new hardware, I don't see any big drop in desktop environment.
On a desktop machine, a slightly increased risk to system availability is totally okay. On a server machine, it's a harder call, especially if the security benefit is only a defense-in-depth measure. For most servers out there, if they're running arbitrary code as an unprivileged user, something has already gone horribly wrong.
I agree with it in general, but wouldn't go with the same conclusions. Upstream linux also sometimes results in random deadlocks and issues that people try to debug for weeks. That's what the rc cycle (6+ of them usually) is for.
The unstabilities of grsec are kind of a side-effect of not many people looking at it. If this change happened on lkml, I'd bet someone would pick up the OpenAFS issue earlier. I don't think anyone from grsec team would be actively opposed to more users testing the releases.
Some of these patches in grsec are also controversial.
It's not fair to discuss grsec as a whole, when asking "why hasn't it been merged?". The /tmp symlink protection was a personal pet peeve of mine for many years. As implemented by grsec, it completely eliminated an entire class of vulnerabilities. It also had zero overhead and was a very small patch. It frustrated me to no end that it took years to land in mainline. When it finally did, nothing broke (afaik). I can't understand at all the years of resistance.
However, large parts of grsec were basically a competitor to SELinux. If you disagree with the assertion that selinux is fundamentally broken, then you have parts of grsec that don't belong in mainline.
The chroot restrictions broke BIND on my installations, which happen to be one of the most commonly chroot() users in standard deployments.
grsec has some great memory protection capabilities. There should at least be a conversation about some of this going mainline.
Why do you think so? RBAC is an optional part that requires extra configuration to even activate. There's a lot of benefit in running grsec kernel with SELinux as MAC. These features neither depend on RBAC nor even use it.
It's kind of like smack, selinux, apparmor, yama, etc. You can think some of them are broken/worse than others. You're not forced to use them.
Because even apart from straight-up bugs like the one being discussed, they are full of design decisions that fail in that direction, by design. Given the option between accidentally allowing malicious code to work and accidentally breaking benign software, Linux upstream prefers the former; grsec prefers the latter. For grsec it is better to have a kernel panic than an information disclosure, if those are your two options; for Linux upstream the preference is backwards.
So if grsec is adding a safety option (in this case it was fundamentally caused by a check for integer overflow, IIRC, and getting things to work with that check), they're willing to risk breaking code and figuring it out later. LKML is willing to risk having the safety option not apply in all cases, but not risk breaking code that previously worked.
Working through the stuff grsec provides and making sure it fits the LKML worldview (i.e., it only fails closed when the risk of false positives is sufficiently low or the admin has an option), both in design and implementation, is slow work. But it is happening.
HardenedBSD tried to upstream their ASLR patch and the developer didn't manage to address the patch review comments (if you check the Phabricator ticket) and another FreeBSD kernel dev (Belousuv) contributed his ASLR patch upstream in FreeBSD-11. Before this happened, HardendedBSD decided to not try upstreaming stuff, but they still, like GRsecurity, have very useful security enhancements and it only hurts FreeBSD users having to decide between FreeBSD and HardednedBSD (or a HardendedBSD variant of FreeNSD or OPNSense).
I know firsthand how strong personalities can be very hard to work with if you cannot get your technical argument across, so I don't really blame Spender, but it's a disservice to all users. It's not like music where you can listen to both bands. A computer starts up with one kernel at a time.
It might actually help to get the PaX/GRsecurity team and core kernel lieutenants in a room for a couple hours to talk it out and realize they're not disagreeing.
Comparing HBSD to grsecurity is insulting to grsecurity, there is no similarity.
For example, if you want to introduce a new filesystem that requires VFS features not yet present, you submit those features first and make a case for their usefulness beyond your own use case. Then you submit your new filesystem adapted to use those features as they where (then already) merged.
Failing to go through this process results in failure to be accepted for inclusion in mainline. Sure, this makes some useful stuff linger by the wayside (usually due to ego clashes), but it's the only way to maintain any sanity in a project as large and active as the Linux kernel and that's a good thing in the long run.
But there's a pretty well documented anti-grsecurity sentiment on the lists dating waaaay back. So if I were them I wouldn't be necessarily convinced that I should invest my time in slicing to begin with. ;)
grsecurity is a big collection of a bunch of different techniques. It isn't a total rethink of the Linux kernel, it is a bunch of patches spread over a large surface area. Some of the changes are far-reaching, yes, but even so, each of the techniques represented in grsecurity could be broken into independent patches. So, why haven't they been? (I honestly don't know why. It's not something I follow closely.)
Grsec upstream argues that only accepting part of the whole is worse than having their patches outside mainline in bulk, because it would give developers and users a false sense of security to only provide some of the hardening grsec does.
See this[1] LWN article from 2009, which is a kernel developers post with a comment retort by some grsec developers.
[1]: https://lwn.net/Articles/313621/
The frustration is that we are now seven years later and the situation has only gotten worse - plenty of kernel exploits have emerged, no distro is shipping grsec comprehensively, grsec itself had to stop providing stable releases, and it has become more religious than logical as to why many critical features, like the internal bug prevention functionality, never will be mainlined and will be re-implemented with much less thoroughly tested surrogates.
I don't have a lot of sympathy for that position. I respect the work, but not the hostile-to-collaboration approach.
Yep. They keep coming across as treating security as something binary. Either it is secure or it is not.
And the moment even the most convoluted of CVEs gets published, anything affected is in their view insecure. And thus needs to be taken out of production until a fix has been applied.
Frankly it seems quite a number of the most outspoken in the community is not in it for the hohum daily security process, but as some kind of grand joust with "the man". Thus their low water mark for security is "can it stop the NSA".
The dozens of changes which you refer to as containers are very much bolted-on to both FreeBSD and Solaris. It would have been nice of that wasn't true, but it's just not realistic to to back to the drawing board netiher for FreeBSD nor Linux to get this single feature.
Just think about cgroups, which required some rather deep reworking of several subsystems in Linux, took years to get in place. And that's just one of many pieces that containers can potentially make use of.
Most regressions are introduced in hardware drivers and those are the largest part of the kernel and the part that sees most churn. It's great that we don't see more regressions, actually, though the Intel DRM drivers have gotten worse in quality over the last year.
And that's how you end up with clearly superior subsystem implementations (BFQ) that linger outside the kernel as GP mentions. Because a professor doing free work should somehow find a way to hack a cohesive working subsystem into the mess which is the old codebase so as to satisfy the maintainers (who are paid to work on this stuff) need for a gradual transition (which will eventually rip out all of the old code anyways).
Linux supports quite a lot of different workloads on quite a lot of different hardware. Looking for the best possible performance while ensuring reliability is a very big task and a very big responsibility not to be taken lightly by stereotyping kernel maintainers as some villains looking to make victims out or poor, well-intentioned, contributors.
Also, arguing that contributors don't have the means to go through a public review process intended to result in better code doesn't really add much credibility to the original code, does it? (Not saying that's the case with BFQ either.)
There have been many instances in the past where "clearly superior" patches ended up having pathological behavior for many workloads. Something that would only be discovered after impacting a lot of users if it weren't for the review processes in place. Some of these were merged anyway (but not made default) while some others didn't prove to provide enough improvement (even in the cases they optimize for) to justify the extra bloat.
> That's just it, isn't it? What makes it clearly superior? (BTW, I'm not arguing it isn't.)
A) There are is a range of benchmarks which support that conclusion across various hardware and workloads. [0][1]
B) It is my understanding that the current day CFQ is a complicated code-base with various engineering improvements that don't have formal specs or theoretical guarantees, the improvements BFQ brings have theoretical underpinnings [2][3], at the least a spec other than "read the code to understand how and why".
> Looking for the best possible performance while ensuring reliability is a very big task and a very big responsibility not to be taken lightly by stereotyping kernel maintainers as some villains looking to make victims out or poor, well-intentioned, contributors.
It's definitely not my intention to villainize kernel developers (for example Tejun Heo appears to be highly supportive in [4]) - and I don't think Paolo is a victim here; but I do think that both casual and professional users are hurt by the end result.
> Also, arguing that contributors don't have the means to go through a public review process intended to result in better code doesn't really add much credibility to the original code, does it? (Not saying that's the case with BFQ either.)
I mean to the extent that you are talking about ripping out a sub-system for a new one, it's nearly impossible to really talk about having the means. The later is I presume a non-trivial task even for someone with a long track-record of good engineering and maintenance. Paolo is if anything also a very good engineer - but that's not even the case for a lot of academics. I guess from my perspective if an Academic provides you with formalized improvements + benchmarks + working code that's already really, really great, there is very significant reason to have engineers with a long track record of reliability who can review the specs, implement/verify/improve the code to get it up to standards, and to deal the with requirements/politics for making these changes. Again my understanding can be totally off here, I'm not a kernel developer - I am just a user who patches with BFQ (and CK for my personal machine) since given the current process improvements do not seem to be forthcoming.
[0] http://algo.ing.unimo.it/people/paolo/disk_sched/results.php
[1] http://algo.ing.unimo.it/people/paolo/disk_sched/comparison....
[2] http://algo.ing.unimo.it/people/paolo/disk_sched/description...
[3] http://algo.ing.unimo.it/people/paolo/disk_sched/bfq-techrep...
- Recognizing known attacks (as with virus signatures) is effective.
- Patch and release is effective.
That sort of worked back in the script kiddie era, when the attacker was some kid in their parents' basement. They stopped working when the attacker became organized crime, usually from Russia and China. They became hopeless when the attacker became nation-states.
{{citation-needed}}
You don't think people bounce through boxes in jurisdictions with cultural/linguistic/political LE collaboration challenges on purpose? I'd wager a fair amount of so-called Chinese traffic is in fact foreign in origin.
https://twitter.com/marcan42/status/724745886794833920
This is really poor communication from both sides.
This is, of course, a rethorical question that usually gets an answer that vaguely reminds me of the Reiser4 threads of yesteryear.
In case of grsecurity Linus tends to disagree with their philosophy of what leads to more secure system and what doesn't. And if Linus thinks you're wrong, then you're wrong, period. So grsecurity crowd would have to bow and compromise (which collides with their philosophy) on what stuff gets integrated, how, etc.
What's good enough according to Torvalds is not good enough according to them. But let's say they kneel. They'd have to not only cut their baby in pieces and massage it over and over again, discussing every detail of design and implementation on the list for Linus to mercifully accept it, they'd invest time pleasing him instead of doing what they care about: improving security.
So it's a lose-lose for them. And mainline doesn't seem to care about security (contrary to popular belief I guess). So yeah, there you have it.
What leads to better security? Having an out-of-tree patch that few people use, or include parts of it in mainline thus benefiting everyone? Eventually most, if not all, of their changes would reach mainline. Also, is it good for security to accept bulk patches touching all kinds of sensitive parts of the kernel? I'd say that the existing process is better for security in the long run.
This process isn't about bowing to anyone, and thinking about patches as someone's baby doesn't help either. This happens every day with patches from companies with deep pockets and big influence and they end up going along with the program to get their stuff accepted. The result is invariably better than the original bulk patch.
Yeah, I'm exaggerating Linus' involvement. But for me there's always personality stink around projects this size. And it's obviously not different for grsecurity itself or, say, OpenBSD. But this definitely has some major upsides too. Basically what I'm trying to say is that even this over the top image of Linus-the-Destroyer should not be read as negative. Everything is shades of gray.
Having said that - there's a history of clashes between prominent Linux devs and grsecurity. At this point anyone (Linus or otherwise) would be more than justified shying away from any cooperation with grsecurity. At the same time this doesn't prevent active developers with commit rights from cherry-picking changes (which happens).
This seems very unfair, given that grsec isn't a buggy pile of shit.
Compared to SELinux, RBAC misses some very specific features, like dbus calls filtering for example, but otherwise those 3 systems are fairly comparable. RBAC uses AppArmor approach of filtering based on paths rather than inodes/attributes.
But grsec as a whole is much larger. It prevents way more attacks at kernel and userspace level than LSM implementations can see. https://grsecurity.net/compare.php should give you a general idea.
Also, there's nothing preventing you from using selinux, apparmor, or something else with grsec kernel - they can still run together.