Re: Security and PAX

[rhino64%epost.ch@localhost]

Hi,

finally I have tried to use these parameters to compile pseudo statically a big
program (zsh) but without too much succes (the linking stage failed
with an error with the .RODATA segment of some libs).

Probably, I will have to build static executables for some usage (mainly 
to have executable working across many version of OS and over a long
period of time) and dynamic for other usages (like SSH
or some other services where ASLR might be important).

However, it seems that the documentation (man security (7)) is wrong
because for non PIE programs, only the stack address is random.
At least this was the case with all the tests I have done by compiling
statically or dynamically (under netbsd 6.1.5) the small example program.

     For non-PIE (Position Independent Executable) executables, the NetBSD _P_a_X
     _A_S_L_R implementation introduces randomization to the following memory
     regions:

           1.   The data segment
           2.   The stack

     For PIE executables:

           1.   The program itself (exec base)
           2.   All shared libraries
           3.   The data segment
           4.   The stack

     While it can be enabled globally, NetBSD provides a tool, paxctl(8), to
     enable _P_a_X _A_S_L_R on a per-program basis.

kind regards,

rhino64

On Sun, Jun 07, 2015 at 06:59:31PM +0000, Christos Zoulas wrote:

> 
> Yes, but...
> 
> $ cc -static -Wl,-I/libexec/ld.elf_so -fpie -Wl,-pie pie.c -lc_pic
> 
> 1. Our specs are broken for static and you need to explicitly specify
>    the interpreter
> 2. You need to link against the pic version of libc
> 
> $ file ./a.out
> ./a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 7.99.16, not stripped
> 
> And it is not a "statically linked" binary.
> 
> $ ldd ./a.out
> ./a.out:
> 
> But it does not depend on any shared libraries, other than the dynamic
> linker itself...
> 
> christos