Diff for /wikisrc/pkgsrc/hardening.mdwn between versions 1.7 and 1.49

version 1.7, 2016/03/17 13:27:17 version 1.49, 2021/10/02 14:48:27
Line 1 Line 1
 [[!meta title="Hardening pkgsrc"]]  This page has been moved to [the pkgsrc guide](//www.NetBSD.org/docs/pkgsrc/hardening.html).
 [pkgsrc](http://www.pkgsrc.org/) supports a number of mechanisms that are meant  
 to improve the security of compiled binaries. They can be individually enabled  
 in `mk.conf`, and consist of:  
 * `PKGSRC_MKPIE`: forces the creation of PIE (Position Independent  
   Executables) when supported on the current platform. This option is necessary  
   to fully leverage ASLR as a mitigation for security vulnerabilities.  
 * `PKGSRC_USE_FORTIFY`: allows substitute wrappers to be used for commonly used  
   functions that do not bounds checking regularly - but could in some cases.  
 * `PKGSRC_USE_RELRO`: this also makes the exploitation of some security  
   vulnerabilities more difficult in some cases.  
 * `PKGSRC_USE_SSP`: enables stack-smashing protection (again, on supported  
 # Caveats  
 ## Problems with `PKGSRC_MKPIE`  
 ### No support for cwrappers  
 As of the time of this article `PKGSRC_MKPIE` is not supported by  
 `pkgtools/cwrappers` (`USE_CWRAPPERS` in `mk.conf`).  
 ### Packages failing to build  
 A number of packages may fail to build with this option enabled. The failures  
 are often related to the absence of the "-fPIC" compilation flag when building  
 libraries or executables (or ideally "-fPIE" in the latter case). This flag is  
 added to the `CFLAGS` already, but requires the package to actually support it.  
 #### How to fix  
 These instructions are meant as a reference only; they likely need to be adapted  
 for many packages individually.  
 For packages using `Makefiles`:  
     MAKE_FLAGS+=        CFLAGS=${CFLAGS:Q}  
 For packages using `Imakefiles`:  
 ### Run-time crashes  
 Some programs may fail to run, or crash at random times once built as PIE. Two  
 scenarios are essentially possible:  
 * actual bug in the program crashing, exposed thanks to ASLR/mprotect;  
 * bug in the implementation of ASLR/mprotect in the Operating System.  
 ## Problems with `PKGSRC_USE_FORTIFY`  
 ### Packages failing to build  
 This feature makes use of pre-processing directives to look for hardened,  
 alternative implementations of essential library calls. Some programs may fail  
 to build as a result; this usually happens for those trying too hard to be  
 portable, or otherwise abusing definitions in the standard library.  
 This will require a modification to the program, or disabling this feature for  
 part or all of the build.  
 ### Run-time crashes  
 Just like with `PKGSRC_MKPIE` above, this feature may cause some programs to  
 crash, usually indicating an actual bug in the program. The fix will typically  
 involve patching the original program.  
 ## Problems with `PKGSRC_USE_RELRO`  
 ### Performance impact  
 For better protection, full RELRO requires every symbol to be resolved when the  
 program starts, rather than lazily at run-time. This will have more impact on  
 programs using a lot of symbols, or linked to libraries exposing a lot of  
 symbols. Therefore, daemons or programs otherwise running in background are  
 affected only when started. Programs loading plug-ins at run-time are affected  
 when loading the plug-ins.  
 The impact is not expected to be noticeable on modern hardware, except in some  
 cases for big programs.  
 ## Problems with `PKGSRC_USE_SSP`  
 ### Packages failing to build  
 The stack-smashing protection provided by this option does not work for some  
 programs. The two most common situations in which this happens are:  
 * the program makes use of the `alloca(3)` library call (memory allocator on the  
 * the program allocates variables on the stack, with the size determined at  
 Both cases will require a modification to the program, or disabling this feature  
 for part or all of the build.  
 ### Run-time crashes  
 Again, this feature may cause some programs to crash, usually indicating an  
 actual bug in the program. Patching the original program is then required.  
 # Auditing the system  
 The illusion of security is worse than having no security at all. This section  
 lists a number of ways to ensure the security features requested are actually  
 _These instructions were obtained and tested on a system derived from NetBSD 7  
 (amd64). YMMV._  
 ## Checking for PIE  
 The ELF executable type in use changes for binaries built as PIE; without:  
     $ file /path/to/bin/ary  
     /path/to/bin/ary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 7.0, not stripped  
 as opposed to the following binary, built as PIE:  
     $ file /path/to/pie/bin/ary  
     /path/to/pie/bin/ary: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 7.0, not stripped  
 The latter result is then what is expected.  
 ## Checking for RELRO  
 The following command should list a section called `RELRO`:  
     $ objdump -p /path/to/bin/ary  
     /path/to/bin/ary:     file format elf64-x86-64  
     Program Header:  
        RELRO off    0x0000000000000d78 vaddr 0x0000000000600d78 paddr 0x0000000000600d78 align 2**0  
 ## Checking for SSP  
 Building objects, binaries and libraries with SSP will affect the presence of  
 additional symbols in the resulting file:  
     $ nm /path/to/bin/ary  
                      U __stack_chk_fail  
     0000000000600ea0 B __stack_chk_guard  
 This is an indicator that the program was indeed built with support for SSP.  

Removed from v.1.7  
changed lines
  Added in v.1.49

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb