
The Truth about Linux 4.6 - jonbaer
https://forums.grsecurity.net/viewtopic.php?f=7&t=4476
======
jordigh
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...](http://www.theregister.co.uk/2016/04/27/linux_security_bug_report_row/)

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

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

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

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

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

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

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

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

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

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

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

~~~
zanny
> So, why haven't they been?

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/](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.

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

~~~
digi_owl
> 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".

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

~~~
contingencies
_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.

------
leni536
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](https://twitter.com/marcan42/status/724745886794833920)

This is really poor communication from _both_ sides.

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

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

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

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

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

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

~~~
DominikD
Hey, he crushed quite a few souls! ;)

~~~
mg794613
Come on!let's grow beyond this decade of "being offended"

~~~
DominikD
I didn't say a single word about being offended. :)

------
zxcvcxz
Are any big companies using the grsecurity patches?

~~~
hga
Docker is using Alpine Linux which normally uses grsecurity.

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

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

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

~~~
viraptor
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](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.

------
based2
[https://wiki.debian.org/grsecurity](https://wiki.debian.org/grsecurity)

