Re: How GNU/Linux distros deal with offset2lib attack?

[Greg KH <greg () kroah com>]

On Sun, Dec 07, 2014 at 04:42:12PM -0500, Daniel Micay wrote:
> > And a "well written" option will never have a CONFIG_* option within
> > the .c files, as that's not the normal way to implement features in
> > the Linux kernel.
>
> Needing to maintain invasive changes out-of-tree makes things different.
> It's done in way that minimizes merge conflicts.
>
> > The reason PaX isn't in the main kernel tree is that no one has spent
> > the time and effort to actually submit it in a mergable form.  So
> > please, do so if you think this is something that is needed.
>
> I don't think that's an fair assessment.
>
> There's a small fraction of it that could be split up and pushed
> upstream with a large amount of effort. Lots of people have attempted to
> upstream grsecurity/PaX features in various forms, and there are success
> stories like kptr_restrict, dmesg_restrict, ptrace_scope,
> protected_symlinks and protected_hardlinks features among others.
>
> I have a lot of respect for people like Kees Cook who are willing to
> deal with the politics and endless disappointments. Most people are not
> willing to do that, especially if they aren't being paid.

The fact that no one seems willing to pay anyone to do this, kind of
implies that no one thinks it is worth doing :(

> There was little success in upstreaming stuff like making most vtables
> constant, despite it being an obvious improvement. Some maintainers
> don't see the value, so it doesn't work out. Fixes for info leaks also
> have the same fate, and the stable kernels tend to be missing the ones
> that do land in mainline; unlike the grsec LTS kernels.

What have I missed?  Please tell me if I miss anything you think is an
"info leak", I will be glad to always apply stuff like this.

And the vtable constant stuff is good, it just takes time, but it can be
done.  Hitting a constantly moving target is one thing that causes
problems, but if you know of tree-wide stuff like this that should be
done, let me know, I can help out with that.

> Linux kernel development involves a lot of politics and compromises
> between different priorities.

Like the real world :)

> I don't upstreaming most of the features
> is realistic. Many of them involve ABI changes to fix age old info leaks
> and to implement aggressive userspace exploit mitigations.

Userspace abi changes are hard, if not impossible, but we have done it
for things.  See the recent 32bit Wine breakages as examples of this.

So again, if there are things that we should be "fixing" in the kernel,
please let us, and me specifically, know, and I will be glad to help out
with it.

> The fact that it uses GCC plugins to deal with issues like size
> overflows and vtable constification and thanks to lack of upstream
> interest in improving security. In OpenBSD, these issues are tackled via
> extensive work to modernize the code. It's unrealistic for issues like
> this to be handled without stricter coding guidelines and a willingness
> to accept large patches introducing good practices.

We have very strict coding guidelines, and a huge regression test for
issues like this.  We have rules that get run on every commit so that if
you can model a "bad coding example", we can track it and prevent it
from getting back into the kernel.

We also take huge numbers of patches all over the tree to resolve
different issues.  Yes, not all in one patch, that's not how it works,
it takes more engineering time, but it can be done, and is done, all the
time for very "trivial" things.

> Submitting thousands of constification / size overflow patches and
> somehow landing even half of them is unrealistic. These patches aren't
> really welcome, and telling people that it's all they have to do is just
> setting up more drama.

Then you are doing it wrong.  I'm glad to help out with this if you can
point me at specific examples of things that should be changed.

thanks,

greg k-h