Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ