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.
I ran grsec on servers extensively for several years. This was several years ago so this information may be dated.
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.
> large parts of grsec were basically a competitor to SELinux.
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.
I didn't suggest you were forced to use any feature. I just suggested that "this needs to be merged mainline" becomes cloudier for a certain feature that already has a similar implementation in mainline.
I don't think anyone is realistically talking about merging the whole of grsec as it exists today. All the efforts and requests were always depending on splitting grsec into separate features that can be merged independently. RBAC feature could realistically be denied in favour of existing LSMs, while other features without equivalent solution could be included.
> And on topic: Why can't the grsecurity patches just be merged into the kernel?
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.
Because they have a patchset of thousands of lines and grsec has refused to break them up into parts so that they can be reviewed and patched in incrementally.
Some of these patches in grsec are also controversial.
Couldn't you accept the patch (for copyright purposes) then revert immediately. Then split the patch up and add it in piecemeal if desired - at least kernel programmers could use it if they wished then?
Quite a lot of things. The problem with grsecurity's claim that Linux doesn't care about security is that grsecurity doesn't appear to care about anything but security. They include changes with significant performance impact, changes that break existing userspace programs, and changes that significantly impact the maintainability of the kernel. Security that people can't or won't use doesn't actually make people more secure; usability, performance, compatibility, and other such concerns are all part of building a secure system.
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.
But it also provides bugs, as demonstrated. (As another anecdote, at least as of many years ago, grsec + OpenAFS led to frequent deadlocks that never happened with a stock kernel.) Now of course Linux has tons of bugs too as does every nontrivial patchset being merged into Linux. But grsec has a preference for risking bugs that compromise functionality / uptime but not integrity. Linux upstream has exactly the opposite preference.
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.
Personalities and history of GRsecurity not taken seriously in the past led to a grumpy Spender who now has a hard time collaborating with kernel.org when they are actually funding work in the space. At least that's my impression from following this for years.
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.
HardenedBSD is some young people that have very little experience with C and computer architecture picking bones against some people in the FreeBSD community who have that experience in spades and becoming angsty and upset that they are unable to meet requisites for merge. Altering the VM doesn't happen quickly, especially when you have no track record of working on that subsystem.
Comparing HBSD to grsecurity is insulting to grsecurity, there is no similarity.
That wasn't my impression, but I'm not qualified to judge the diffs on the code level, so I'll note that their changes may possibly be of lower quality than they are advertised.
It is eternally frustrating how valuable kernel features like grsec, the bfq and bfs schedulers (for disk and cpu respectively), and many more hugely useful but not commercially backed (or at least proposed) projects wallow in side trees of Linux mainline. It is just baffling how the grsec patches are ~13? years old now and yet remain out of tree rather than, say, default-off on kconfig, which even then makes no sense - users of the kernel should be getting maximally secure and conservative software first, and then turning off checks to increase performance, not the other way around - having a wild and exploitable kernel you need to use out of tree patches to get under reasonable control.
If there's something that defines the Linux kernel development process is that large/wide changes are never accepted in bulk. Changes must be broken up into independent pieces that make sense by themselves and can be well understood by the people doing the merges.
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.
You don't evolve proper security though a million tiny commits. You design it. This is why containers on Linux will probably never have the security that Solaris or the BSDs have, and this attitude is why. It will never get better until that is rethought, if you're right..
I don't think I buy this argument; at least, I don't think grsecurity backs up this argument.
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.
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.
The irony is that the grsecurity folks complain of limited time and unwillingness to do that work. But, had they done so back then, they wouldn't still be maintaining a huge patchset against the massive moving target that is the kernel. Once a patch is in, it becomes the onus of every kernel developer to not break it. As long as it remains in a silo, nobody has an obligation to not making breaking changes.
I don't have a lot of sympathy for that position. I respect the work, but not the hostile-to-collaboration approach.
This is the problem with grsecurity and the security community in general, I think. grsecurity includes things that are relatively safe and beneficial. It also - for example - redefines integer arithmetic kernel-wide in a way that causes massive false positives and kernel panics. Insisting that if you don't want the parts likely to take critical servers down at the worst possible time for no reason, you may as well not bother is ridiculous, broken, and leads to reasonable people just not bothering.
> This is the problem with grsecurity and the security community in general
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".
> This is why containers on Linux will probably never have the security that Solaris or the BSDs have
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.
Why do you believe that they are opposing activities? I can make a journey by helicopter or by walking but the destination is still the same, however as I walk there someone might point me at a better one.
That's what people used to say about OS kernels, but Linux proved them wrong by evolving the most successful kernel on the planet by almost all measures.
> If there's something that defines the Linux kernel development process is that large/wide changes are never accepted in bulk. Changes must be broken up into independent pieces that make sense by themselves and can be well understood by the people doing the merges.
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).
That's just it, isn't it? What makes it clearly superior? (BTW, I'm not arguing it isn't.)
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.
It's been a while since I've looked at the papers or read the discussion surrounding it's inclusion into the mainline (so I apologize if I get some details wrong), but my understanding regarding the first point is two fold:
> 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.
AFAIK they never tried submitting in bulk so I'm not sure why this (sensible, I think) process is used as an argument against them. I don't know if they tried to post piece by piece (and when/if they gave up).
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. ;)
VFS is a good example of something that's hairy and easy to introduce regressions affecting everyone. That's why Al Viro dissects stuff in detail.
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.
- 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.
the attacker became organized crime, usually from Russia and China
{{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.
If the PLA or Russian mafia really wants something in your network, they will threaten to cut off your spouse's/kid's thumbs. Grsec isn't going to protect against that.
Whenever I read (or hear) about how grsecurity improves things I wonder why it isn't included in mainline, or why isn't it in the process of being included in mainline.
This is, of course, a rethorical question that usually gets an answer that vaguely reminds me of the Reiser4 threads of yesteryear.
It's the same reason other interesting things don't get mainlined from time to time: personalities and opinions. Linus is a loudmouth and he has every right to be like that. It's his playground after all. But this leads to blind spots and dogmatism in areas that ultimately hurt the project.
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.
You overestimate Linus' role in the process. The process is hierarchical and by the time patches reach Linus they're already bulk by the very definition of 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.
You're missing the crucial part: grsecurity is not a company with deep pockets. There's little to no incentive for them to spend time on doing something, somewhere they're not terribly welcome. :)
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).
I always think it's amusing when the guy who presides over one of the largest software projects in history, with probably the largest number of contributors, is painted as 'the destroyer' or similar.
I'm not sure why they went with pivot_root -- there's already code to deal with handling symlinks and all of their paths properly within Docker containers from the host (which I helped write and merged something like 2 years ago). I would've thought the obvious way of doing it would be to modify pkg/archive ...
Docker doesn't boot a kernel. It uses host kernel features. People who use alpine as a base for Docker images are just using the root filesystem from an alpine install.
I know, but I've heard that it can run Linux on OS X, so I was wondering if it now boots kernels as well. Basically, Docker is ezjail with financial backing and PR.
Grsec consists of a few systems. One of them is RBAC, which is an access control part for userspace applications. It works similar to selinux/apparmor, but it's not based on LSM interface (as far as I know, but feel free to correct me).
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.
HN's dupe finder isn't perfect and it has no sections, so rather than having new submissions I thought it'd be better to reuse existing entries. That said, I can see how my comment may appear as it did to you, but that wasn't my intention. Maybe I should have deep-linked.
On HN the convention is to link to previous submissions if there's interesting discussion there, but not otherwise. We allow reposts as a way of giving interesting stories multiple chances at attention—otherwise most interesting stories would be sunk by randomness, making this place less interesting.
(And thanks for responding to a provocative comment with exemplary civility!)
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.