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.