File:  [NetBSD Developer Wiki] / wikisrc / pkgsrc / hardening.mdwn
Revision 1.23: download - view: text, annotated - select for diffs
Sun Nov 5 23:54:11 2017 UTC (5 years ago) by gdt
Branches: MAIN
CVS tags: HEAD
Explain more

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

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