Date: Sun, 10 Apr 2011 13:21:47 +0100 From: Djalal Harouni <tixxdz@...ndz.org> To: owl-dev <owl-dev@...ts.openwall.com> Subject: Userland hardening ideas for Owl Hi list, In this mail I will try to discuss some ideas related to userland hardening that can perhaps _fit_ in the Owl project ideas wiki page http://openwall.info/wiki/ideas Corrections and feedback are welcome. o PT_PAX_FLAGS ELF header support: Since there are plans to include some grsecurity/PaX patches, I was wondring if the Owl team is planning to include the kernel and the binutils patches that will generate and handle binaries with the PT_PAX_FLAGS ELF header or just use the standard protections offered by the GNU toolchain. Quoting PaX doc: "Enabling this option will allow you to control PaX features on a per executable basis via the 'paxctl' utility available at http://pax.grsecurity.net/. The control flags will be read from a PaX specific ELF program header (PT_PAX_FLAGS). This marking has the benefits of supporting both soft mode and being fully integrated into the toolchain (the binutils patch is available from http://pax.grsecurity.net)". This feature will make some other ELF headers generated by the GNU toolchain useless. The advantage of this is: you can activate all the protections for all binaries, and to disable a specific protection for a specific binary we just use the 'paxctl' tool to edit the PAX_FLAGS ELF header. So what Owl people think about this ? or just use the standard features of the GNU toolchain ? most of the protections will be activated if the kernel is configured with the appropriate security features. (I hope that I'm not missing something). o Add the ability to re-exec itself or randomize VMA when forking: Critical code which use the privilege separation or the master and workers schemes can share the same VMA space between its processes. Any leak (e.g: debug info/msg) in a worker process can be used to guess the address space of the master process. Of course using PIE (Position Independent Executable) is a must, but what about long running processes or servers in a multiuser system ? in this case the ASLR effect will be reduced. Perhaps some critical code can be patched to re-execute itself, OpenSSH re-execute itself for each new accepted connection, which means that the master and all the workers will have a different VMA space, and this applies perfectly to OpenSSH. Other critical software (big programs) can't do the same thing since they must handle a lot of connections with scalability in mind, but in the other hand it would be better if the different processes of a long running server do not have the same VMA space. Another idea (perhaps it's not practical) would be to randomize the VMA space when forking, but I do not know if this is practical, or how it can be achieved or how this can affect the optimization of copy-on-write technique. Thanks. -- tixxdz http://opendz.org
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.