previously on this list Aaron Zauner contributed: I agree with MACs being questionable in that they are an extra *FINAL* layer only really effective on simple systems where they arguably aren't needed, can be circumvented by kernel exploits and often MACs are used on systems despite the wide ranging capabilities of DACs being ignored which are more reliable and less complex
(RedHat/Fedora failing to realise the power of existing tech like groups is a classic example, Debian is better here). However I do believe Debian and Linux should be doing a lot more outside of grsec/pax/gentoo hardened. I could be wrong but I'm under the impression that Ubuntu is ahead (maybe just as more bleeding edge and PAE by default etc. though I am surprised they don't ship two kernels on their install or two cds for those few idiotic years intel laptops dropped PAE for). > I'm aware of this. Some of them also implement PaX (or W^X in OpenBSDs > case). That said, it will probably improve security a bit, in particular > against skiddies just running scripts of the web. But any serious > attacker may circumvent stack canaries anyway. Thats not deep magic > anymore. There are now automated tools to make ROP/return-to-lib-c > attacks particularly easy to pull off (finding ROP gadgets > automatically, even writing weaponized exploit code and so forth). Your links are very old and miss out combining security features. OpenBSD employs randomisation all over and recently starting with the boot loader. you would have a real hard time making it run out of entropy too. I'm told it's Not AS good but is a good start, has debian considered running haveged by default? The average linux system is lagging behind. http://www.openbsd.org/papers/ru13-deraadt/ The linux code may be less integrated as it is just the kernel but is all there as shown below and mentioned in Theo's Talk above. http://pax.grsecurity.net/docs/pax.txt http://pax.grsecurity.net/docs/PaXTeam-LATINOWARE12-PaX-linux-security.pdf An abstract on this very subject _______________________________________________________________________ (1) introduce/execute arbitrary code (2) execute existing code out of original program order (3) execute existing code in original program order with arbitrary data For example the well known shellcode injection technique belongs to (1) while the so-called return-to-libc style technique belongs to (2). Before going into the analysis of the above techniques, let's note an often overlooked or misunderstood property of combining defense mechanisms. Some like to look at the individual pieces of a system and arrive at a conclusion regarding the effectivenes of the whole based on that (or worse, dismiss one mechanism because it is not efficient without employing another, and vice versa). In our case this approach can lead to misleading results. Consider that one has a defense mechanism against (1) and (2) such as NOEXEC and the future userland changes in PaX. If only NOEXEC is employed, one could argue that it is pointless since (2) can still be used (in practice this reason has often been used to dismiss non-executable stack approaches, which is not to be confused with NOEXEC however). If one protects against (2) only then one could equally well argue that why bother at all if the attacker can go directly for (1) and then the final conclusion comes saying that none of these defense mechanisms is effective. As hinted at above, this turns out to be the wrong conclusion here, deploying both kinds of defense mechanisms will protect against both (1) and (2) at the same time - where one defense line would fail, the other prevents that (i.e., NOEXEC can be broken by a return-to-libc style attack only and vice versa). _______________________________________________________________________ Personally I look forward to the day that code is written with these security features in mind and it is realised that browser rendering speed is important but JIT needs to go. WRT heartbleed it is quite shocking that this memory handling was applied to all builds. http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse Building exploit mitigations isn’t easy. It’s difficult because the attackers are relentlessly clever. And it’s aggravating because there’s so much shitty software that doesn’t run properly even when it’s not under attack, meaning that many mitigations cannot be fully enabled. But it’s absolutely infuriating when developers of security sensitive software are actively thwarting those efforts by using the world’s most exploitable allocation policy and then not even testing that one can disable it. -- _______________________________________________________________________ '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/67745.48677...@smtp129.mail.ir2.yahoo.com
