The Truth about Linux 4.6

https://forums.grsecurity.net/viewtopic.php?f=7&t=4476

by jonbaer • 10 years ago

144 67 10 years ago

forums.grsecurity.net

jordigh• 10 years ago

That's a lot of trash-talking from someone who knows how to dish it but not take it:

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.

striking• 10 years ago

wrt link: Marcan's only crime was being a little cheeky. It didn't warrant the total meltdown/blockfest spender had.

And on topic: Why can't the grsecurity patches just be merged into the kernel?

GunboatDiplomat• 10 years ago

My understanding is that it breaks things.

verroq• 10 years ago

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.

technion2• 10 years ago

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.

geofft2• 10 years ago

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.

ashitlerferad• 10 years ago

I don't think spender/PaXTeam want their stuff merged.

Animats• 10 years ago

The two big security falsehoods:

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

contingencies2• 10 years ago

the attacker became organized crime, usually from Russia and China

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.

coredog64• 10 years ago

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.

zanny2• 10 years ago

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.

CrLf5• 10 years ago

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.

DominikD5• 10 years ago

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

cyberpunk• 10 years ago

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

cm35• 10 years ago

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.

forgotpwtomain2• 10 years ago

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

CrLf5• 10 years ago

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.

DominikD5• 10 years ago

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.

CrLf5• 10 years ago

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.

rodgerd• 10 years ago

vaguely reminds me of the Reiser4 threads of yesteryear.

This seems very unfair, given that grsec isn't a buggy pile of shit.

zxcvcxz• 10 years ago

Are any big companies using the grsecurity patches?

josh64• 10 years ago

I think BlackBerry use them on their Android kernels.

hga• 10 years ago

Docker is using Alpine Linux which normally uses grsecurity.

cm35• 10 years ago

Does Docker boot a kernel?

contingencies2• 10 years ago

Docker just resolved a critical compatibility issue it had with most reasonably useful configurations of grsec... see https://github.com/docker/docker/issues/20303 which I opened, and https://github.com/docker/docker/pull/22506 which solved it.

viraptor6• 10 years ago

That doesn't give you any improvement in the container by default. Only the host's kernel matters in case of grsec.

cyphar2• 10 years ago

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.

cm35• 10 years ago

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.

kev009• 10 years ago

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.

cm35• 10 years ago

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.

massysett• 10 years ago

How does grsecurity compare to SELinux and AppArmor? Aren't SELinux and AppArmor both in the kernel?

viraptor6• 10 years ago

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.

leni536• 10 years ago

I lot of people here wonder why grsec isn't merged into mainline. I just read this recently related to grsec:

https://twitter.com/marcan42/status/724745886794833920

This is really poor communication from both sides.

Karunamon• 10 years ago

Sounds like someone WTFed at garbage code manifesting in an insane failure case and the author threw a temper tantrum.

based2• 10 years ago

https://wiki.debian.org/grsecurity

The Truth about Linux 4.6

Related Stories