[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20110410122147.GA27683@dztty>
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.
