Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Sun, 10 Apr 2011 13:21:47 +0100
From: Djalal Harouni <>
To: owl-dev <>
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

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  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".

  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



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.