previously on this list Carlos Alberto Lopez Perez contributed: > > Now shipping grsec is a really good idea. I'd like to see that as well. > > There has been an attempt to provide an official grsec-flavour of the > Debian kernel, but it didn't worked: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090
Interesting and the opposition to it (aside from the driver backporting and security patching amalgamation, the intricacies of which I am unsure of, but a resolution looked offered) seems rather unreasonable and born of mainly mis-understandings. KMS - You can run X11 without priv I/O which is a major hole that can be used to bypass things like selinux though you may need to change your kernel boot line to enable KMS early. You can also run X11 with priviledge seperation and why linux hasn't merged OpenBSDs patches yet beats me. XEN - I understand the practicalities of testing many architectures but it is arguable that user testing on bare hardware is more accurate and I fail to see why that should be a significant blocker. Virtualisation as a security tool has also been proven to be a false premise in that it adds complexity and new attack vectors like Timing attacks and so I see many Grsec advocates avoiding it anyway. A message could be added to the kernel description about it to stop users bugging devs of course. SELINUX - RBAC is a more robust offering than SELINUX which has had exploits due to LKM and whilst policies are more readily portable from say Fedora, RBAC is actually far easier to use for a user, especially the policy file and auto generation mode. Doesn't the kernel already have multiple RBAC systems in the security config section so I see no reason to argue it is undesired or should be patched out. JIT/mprotect - You do need paxctl marking in the default everything enabled configuration, for binaries like browsers (if I remember right -m for firefox, -r for chrome ironically due to it's sandbox). -m is needed for a few things like xfce4-mixer, various video playing but not gnome-alsamixer and parole for some video types. I believe the mprotect (-m) equivelent that blocks JIT (execution of compiled at runtime code) is the part that OpenBSD has disabled globally by default and enabled via malloc.conf. If it was widely known it would also generally be easy to make code work with mprotect enabled and I don't believe the performance hit would matter outside the context of this browsers js is fastest but can only be shown by measurement and not users experience especially when most care about rendering speed. Getting main stream distros to ship grsec would be a first step to understanding the issue of JIT as mentioned by Ted Unangst in his heartbleed page and making the next step in security for all. If that happened Linux/Unix would leapfrog Windows in all aspects of security and not just userland, ironically primarily due to userland coding choices and this education would greatly help OpenBSD and Gentoo Hardened too. Brad Spenders comments were taken out of context, he did not say it would be better if he just offered a .deb. He said you are more likely to get that than him splitting out his RBAC and other parts. He feels very strongly about RBAC and other features working in tandem to prevent exploits. I am sure he had no intention of providing a .deb and so this was him being polite whilst probably swearing in his head. I don't know the full story but I believe he gave up on upstream merging many years ago as he was spending more time arguing/educating than working on security improvements. I think kernel.org is probably much more receptive now the Windows kernel has some of these features and their benefits have been proven but I expect he sees that bridge as something he personally doesn't want to get sucked into. The Windows kernel has some of these features that are largely unused by userland but as they are now there more will and do use them (Windows has progressed since DEP in XP which was completely unused and rather rubbish). Linux and all Unix-like systems would really benefit if Linux atleast got into a position akin to Windows where that could naturally progress and I believe Unix userland devs may be more receptive to these security problems once understood. whereas pressure building and explosion is likely to cause fallout of multiple kinds ;-). A position where responses surmount to, yeah but no-one runs grsec or Gentoo hardened or OpenBSD anyway is unhealthy as a counter-response yeah but many run Windows would simply blow up the thread. p.s. Even if things break many will be happier still, OpenBSD pro-actively breaks things because then bugs can be fixed properly including firefox which mainly works just fine on OpenBSD. Debian and all of Unix-like has benefitted from this bug-fixing so why not benefit more. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd _______________________________________________________________________ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) _______________________________________________________________________ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/931879.29654...@smtp141.mail.ir2.yahoo.com
