[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5484C9B4.6030507@gmail.com>
Date: Sun, 07 Dec 2014 16:42:12 -0500
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: How GNU/Linux distros deal with offset2lib attack?
> 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.
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.
Linux kernel development involves a lot of politics and compromises
between different priorities. 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.
For example, PaX ASLR breaks code making incorrect assumptions about the
mmap hint parameter / address space layout. There are at least a dozen
cases of this in various official Arch Linux packages.
PaX is now making heavy use of GCC plugins to alter code generation in
order to implement many of the hardening features. Some of these also
change the semantics of the language. I don't think that's ever going to
be merged upstream, but those features have a high value. For example,
KERNEXEC provides a software implementation of SMEP and enforces RO/NX
pages across the kernel - fully eliminating RWX pages.
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.
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.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
