File:  [NetBSD Developer Wiki] / wikisrc / pkgsrc / hardening.mdwn
Revision 1.28: download - view: text, annotated - select for diffs
Tue Nov 7 02:00:44 2017 UTC (5 years ago) by khorben
Branches: MAIN
CVS tags: HEAD
Add a caveat for FORTIFY

    1: [[!meta title="Hardening pkgsrc"]]
    2: 
    3: A number of mechanisms are available in
    4: [pkgsrc](https://www.pkgsrc.org/) to improve the security of the
    5: resulting system. This page describes the mechanisms, and gives hints
    6: about detecting and fixing problems.
    7: 
    8: # Mechanisms
    9: 
   10: Mechanisms can be enabled individually in `mk.conf`, and are
   11: individually described below. They are sorted by whether they are
   12: enabled by default, and then by their ordering in `mk/defaults/mk.conf`.
   13: 
   14: Typically, a feature will cause some programs to fail to build or work
   15: when first enabled. This can be due to latent problems in the
   16: program, and can be due to other reasons. After enough testing to
   17: have confidence that user problems will be quite rare, individual
   18: mechanisms will be enabled by default.
   19: 
   20: For each mechanism, see the Caveats section below for an explanation
   21: of what might go wrong at compile time and at run time, and how to
   22: notice and address these problems.
   23: 
   24: ## Enabled by default in the stable branch
   25: 
   26: ### PKGSRC_USE_FORTIFY
   27: 
   28: This allows substitute wrappers to be used for some commonly used
   29: library functions that do not have built-in bounds checking - but
   30: could in some cases.
   31: 
   32: TODO: Explain FORTIFY_SOURCE 1 vs 2, and which is used. Give a link
   33: to a good explanation of the technique. Explain if this is gcc specific.
   34: 
   35: It has been enabled by default since pkgsrc-2017Q3.
   36: 
   37: ### PKGSRC_USE_SSP
   38: 
   39: This enables a stack-smashing protection mitigation.
   40: 
   41: TODO: Give a link to a good explanation. Explain if this is gcc
   42: specific or also works with other compilers. Explain if it is C/C++ only.
   43: 
   44: It is enabled by default where known supported since pkgsrc-2017Q3.
   45: 
   46: ## Enabled by default in pkgsrc HEAD
   47: 
   48: ## Not enabled by default
   49: 
   50: ### PKGSRC_MKPIE
   51: 
   52: This requests the the creation of PIE (Position Independent
   53: Executables) for all executables. The PIE mechanism is normally used
   54: for shared libraries so that they can be loaded at differing addresses
   55: at runtime. PIE itself does not have useful security properties.
   56: However, some operating systems support Address Space Layout
   57: Randomization (ASLR), which causes different addresses to be used each
   58: time a program is run. This makes it more difficult for an attacker
   59: to guess addresses and thus makes exploits harder to construct.
   60: 
   61: TODO/check: PIE executables will only be built for toolchains that
   62: support PIE and operating systems known to support ASLR. Currently,
   63: this means NetBSD 8 and later, i386 and amd64.
   64: 
   65: ### PKGSRC_USE_RELRO
   66: 
   67: This also makes the exploitation of some security vulnerabilities more
   68: difficult in some cases.
   69: 
   70: TODO: Explain gcc vs clang, and whether this has broad support or just
   71: a few platforms.
   72: 
   73: TODO: Address "partial" vs "full"; which is this?
   74: 
   75: TODO: Give a link to a comprehensive explanation.
   76: 
   77: ### PKGSRC_USE_STACK_CHECK
   78: 
   79: This uses `-fstack-check` with GCC for another stack protection
   80: mitigation.
   81: 
   82: # Caveats
   83: 
   84: ## Problems with `PKGSRC_MKPIE`
   85: 
   86: ### Recent support for cwrappers
   87: 
   88: `PKGSRC_MKPIE` is only supported by `pkgtools/cwrappers` from the 2017Q3
   89: release on (`USE_CWRAPPERS` in `mk.conf`).
   90: 
   91: ### Packages failing to build
   92: 
   93: A number of packages may fail to build with this option enabled. The failures
   94: are often related to the absence of the `-fPIC` compilation flag when building
   95: libraries or executables (or ideally `-fPIE` in the latter case). This flag is
   96: added to the `CFLAGS` already, but requires the package to actually support it.
   97: 
   98: #### How to fix
   99: 
  100: These instructions are meant as a reference only; they likely need to be adapted
  101: for many packages individually.
  102: 
  103: For packages using `Makefiles`:
  104: 
  105:     MAKE_FLAGS+=	CFLAGS=${CFLAGS:Q}
  106:     MAKE_FLAGS+=	LDFLAGS=${LDFLAGS:Q}
  107: 
  108: For packages using `Imakefiles`:
  109: 
  110:     MAKE_FLAGS+=	CCOPTIONS=${CFLAGS:Q}
  111:     MAKE_FLAGS+=	LOCAL_LDFLAGS=${LDFLAGS:Q}
  112: 
  113: ### Run-time crashes
  114: 
  115: Some programs may fail to run, or crash at random times once built as PIE. Two
  116: scenarios are essentially possible:
  117: 
  118: * actual bug in the program crashing, exposed thanks to ASLR/mprotect;
  119: * bug in the implementation of ASLR/mprotect in the Operating System.
  120: 
  121: ## Problems with `PKGSRC_USE_FORTIFY`
  122: 
  123: ### Packages failing to build
  124: 
  125: This feature makes use of pre-processing directives to look for hardened,
  126: alternative implementations of essential library calls. Some programs may fail
  127: to build as a result; this usually happens for those trying too hard to be
  128: portable, or otherwise abusing definitions in the standard library.
  129: 
  130: This will require a modification to the program, or disabling this feature for
  131: part or all of the build.
  132: 
  133: ### Run-time crashes
  134: 
  135: Just like with `PKGSRC_MKPIE` above, this feature may cause some programs to
  136: crash, usually indicating an actual bug in the program. The fix will typically
  137: involve patching the original program.
  138: 
  139: ### Optimization is required
  140: 
  141: At least in the case of GCC, FORTIFY will only be applied if optimization is
  142: applied while compiling. This means that the CFLAGS should also contain -O, -O2
  143: or another optimization level. This cannot easily be applied globally, as some
  144: packages may require specific optimization levels.
  145: 
  146: ## Problems with `PKGSRC_USE_RELRO`
  147: 
  148: ### Performance impact
  149: 
  150: For better protection, full RELRO requires every symbol to be resolved when the
  151: program starts, rather than simply when required at run-time. This will have
  152: more impact on programs using a lot of symbols, or linked to libraries exposing
  153: a lot of symbols. Therefore, daemons or programs otherwise running in
  154: background are affected only when started. Programs loading plug-ins at
  155: run-time are affected when loading the plug-ins.
  156: 
  157: The impact is not expected to be noticeable on modern hardware, except in some
  158: cases for big programs.
  159: 
  160: ### Run-time crashes
  161: 
  162: Some programs handle plug-ins and dependencies in a way that conflicts with
  163: RELRO: for instance, with an initialization routine listing any other plug-in
  164: required. With full RELRO, the missing symbols are resolved before the
  165: initialization routine can run, and the dynamic loader will not be able to find
  166: them directly and abort as a result. Unfortunately, this is how Xorg loads its
  167: drivers. Partial RELRO can be applied instead in this case.
  168: 
  169: ## Problems with `PKGSRC_USE_SSP`
  170: 
  171: ### Packages failing to build
  172: 
  173: The stack-smashing protection provided by this option does not work for some
  174: programs. The two most common situations in which this happens are:
  175: 
  176: * the program makes use of the `alloca(3)` library call (memory allocator on the
  177:   stack)
  178: * the program allocates variables on the stack, with the size determined at
  179:   run-time.
  180: 
  181: Both cases will require a modification to the program, or disabling this feature
  182: for part or all of the build.
  183: 
  184: ### Run-time crashes
  185: 
  186: Again, this feature may cause some programs to crash, usually indicating an
  187: actual bug in the program. Patching the original program is then required.
  188: 
  189: ### Performance impact
  190: 
  191: The compiler emits extra code when using this feature: a check for buffer
  192: overflows is performed when entering and exiting functions, requiring an extra
  193: variable on the stack. The level of protection can otherwise be adjusted to
  194: affect only those functions considered more sensitive by the compiler (with
  195: `-fstack-protector` instead of `-fstack-protector-all`).
  196: 
  197: The impact is not expected to be noticeable on modern hardware. However,
  198: programs with a hard requirement to run at the fastest possible speed should
  199: avoid using this feature, or using libraries built with this feature.
  200: 
  201: # Auditing the system
  202: 
  203: The illusion of security is worse than having no security at all. This section
  204: lists a number of ways to ensure the security features requested are actually
  205: effective.
  206: 
  207: _These instructions were obtained and tested on a system derived from NetBSD 7
  208: (amd64). YMMV._
  209: 
  210: ## Checking for PIE
  211: 
  212: The ELF executable type in use changes for binaries built as PIE; without:
  213: 
  214:     $ file /path/to/bin/ary
  215:     /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
  216: 
  217: as opposed to the following binary, built as PIE:
  218: 
  219:     $ file /path/to/pie/bin/ary
  220:     /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
  221: 
  222: The latter result is then what is expected.
  223: 
  224: ## Checking for partial RELRO
  225: 
  226: The following command should list a section called `RELRO`:
  227: 
  228:     $ objdump -p /path/to/bin/ary
  229: 
  230:     /path/to/bin/ary:     file format elf64-x86-64
  231: 
  232:     Program Header:
  233:     [...]
  234:        RELRO off    0x0000000000000d78 vaddr 0x0000000000600d78 paddr 0x0000000000600d78 align 2**0
  235: 
  236: This check is now performed automatically if `PKG_DEVELOPER` is set and `RELRO`
  237: is enabled.
  238: 
  239: ## Checking for full RELRO
  240: 
  241: The dynamic loader will apply RELRO immediately when detecting the presence of
  242: the `BIND_NOW` flag:
  243: 
  244:     $ objdump -x /path/to/bin/ary
  245: 
  246:     /path/to/bin/ary:     file format elf64-x86-64
  247: 
  248:     Dynamic Section:
  249:     [...]
  250:       BIND_NOW             0x0000000000000000
  251: 
  252: This has to be combined with partial RELRO (see above) to be fully efficient.
  253: 
  254: ## Checking for SSP
  255: 
  256: Building objects, binaries and libraries with SSP will affect the presence of
  257: additional symbols in the resulting file:
  258: 
  259:     $ nm /path/to/bin/ary
  260:     [...]
  261:                      U __stack_chk_fail
  262:     0000000000600ea0 B __stack_chk_guard
  263: 
  264: This is an indicator that the program was indeed built with support for SSP.
  265: 
  266: # References
  267: 
  268: * <http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html>
  269: 

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