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

version 1.14, 2017/07/09 15:35:02 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).
 A number of mechanisms are available in [pkgsrc](http://www.pkgsrc.org/) to  
 improve the security of the resulting system. They can be enabled individually  
 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  
 * `PKGSRC_USE_STACK_CHECK`: uses `-fstack-check` with GCC for another stack  
   protection mitigation  
 # 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 simply when required 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.  
 ### Run-time crashes  
 Some programs handle plug-ins and dependencies in a way that conflicts with  
 RELRO: for instance, with an initialization routine listing any other plug-in  
 required. With full RELRO, the missing symbols are resolved before the  
 initialization routine can run, and the dynamic loader will not be able to find  
 them directly and abort as a result. Unfortunately, this is how Xorg loads its  
 drivers. Partial RELRO can be applied instead in this case.  
 ## 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.  
 ### Performance impact  
 The compiler emits extra code when using this feature: a check for buffer  
 overflows is performed when entering and exiting functions, requiring an extra  
 variable on the stack. The level of protection can otherwise be adjusted to  
 affect only those functions considered more sensitive by the compiler (with  
 `-fstack-protector` instead of `-fstack-protector-all`).  
 The impact is not expected to be noticeable on modern hardware. However,  
 programs with a hard requirement to run at the fastest possible speed should  
 avoid using this feature, or using libraries built with this feature.  
 # 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 partial 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 full RELRO  
 The dynamic loader will apply RELRO immediately when detecting the presence of  
 the `BIND_NOW` flag:  
     $ objdump -x /path/to/bin/ary  
     /path/to/bin/ary:     file format elf64-x86-64  
     Dynamic Section:  
       BIND_NOW             0x0000000000000000  
 This has to be combined with partial RELRO (see above) to be fully efficient.  
 ## 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.  
 # References  
 * <http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html>  

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

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