File:  [NetBSD Developer Wiki] / wikisrc / pkgsrc / hardening.mdwn
Revision 1.38: download - view: text, annotated - select for diffs
Sun Nov 12 15:15:48 2017 UTC (4 years, 6 months ago) by khorben
Branches: MAIN
CVS tags: HEAD
Also mention PKGSRC_MKREPRO for building reproducibly

    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. It is done by adding a
   40: guard variable to functions with vulnerable objects. The guards are initialized
   41: when a function is entered and then checked when the function exits. The guard
   42: check will fail and the program forcibly exited if the variable was modified in
   43: the meantime. This can happen in case of buffer overflows or memory corruption,
   44: and therefore exposing these bugs.
   45: 
   46: Different mitigation levels are available:
   47: 
   48: * the default ("yes"), which will only protect functions considered vulnerable
   49:   by the compiler;
   50: * "all", which will protect every function;
   51: * "strong", which will apply a better balance between the two settings above.
   52: 
   53: This mitigation is supported by both GCC and clang. It may be supported in
   54: additional compilers, possibly under a different name. It is particularly useful
   55: for unsafe programming languages, such as C/C++.
   56: 
   57: It is enabled by default where known supported since pkgsrc-2017Q3.
   58: 
   59: More details can be found here:
   60: 
   61: * <https://en.wikipedia.org/wiki/Buffer_overflow_protection>
   62: 
   63: ## Enabled by default in pkgsrc HEAD
   64: 
   65: ## Not enabled by default
   66: 
   67: ### PKGSRC_MKPIE
   68: 
   69: This requests the creation of PIE (Position Independent Executables) for all
   70: executables. The PIE mechanism is normally used for shared libraries, so that
   71: they can be loaded at differing addresses at runtime. PIE itself does not have
   72: useful security properties; however, it is necessary to fully leverage some,
   73: such as ASLR.  Some operating systems support Address Space Layout Randomization
   74: (ASLR), which causes different addresses to be used each time a program is run.
   75: This makes it more difficult for an attacker to guess addresses and thus makes
   76: exploits harder to construct. With PIE, ASLR can really be applied to the entire
   77: program, instead of the stack and heap only.
   78: 
   79: PIE executables will only be built for toolchains that are known to support PIE.
   80: Currently, this means NetBSD on amd64 and i386.
   81: 
   82: ### PKGSRC_MKREPRO
   83: 
   84: With this option, pkgsrc will try to build packages reproducibly. This allows
   85: packages built from the same tree and with the same options, to produce
   86: identical results bit by bit. This option should be combined with ASLR and
   87: `PKGSRC_MKPIE` to avoid predictable address offsets for attackers attempting to
   88: exploit security vulnerabilities.
   89: 
   90: More details can be found here:
   91: 
   92: * <https://reproducible-builds.org/>
   93: 
   94: ### PKGSRC_USE_RELRO
   95: 
   96: This also makes the exploitation of some security vulnerabilities more
   97: difficult in some cases.
   98: 
   99: Two different mitigation levels are available:
  100: 
  101: * partial: the ELF sections are reordered so that internal data sections
  102:   precede the program's own data sections, and non-PLT GOT is read-only;
  103: * full: in addition to partial RELRO, every relocation is performed immediately
  104:   when starting the program (with a slight performance impact), allowing the
  105:   entire GOT to be read-only.
  106: 
  107: This is currently supported by GCC. Many software distributions now enable this
  108: feature by default, at the "partial" level.
  109: 
  110: More details can be found here:
  111: 
  112: * <http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html>
  113: 
  114: ### PKGSRC_USE_STACK_CHECK
  115: 
  116: This uses `-fstack-check` with GCC for another stack protection mitigation.
  117: 
  118: It asks the compiler to generate code verifying that it does not corrupt the
  119: stack. According to GCC's manual page, this is really only useful for
  120: multi-threaded programs.
  121: 
  122: # Caveats
  123: 
  124: ## Problems with `PKGSRC_MKPIE`
  125: 
  126: ### Recent support for cwrappers
  127: 
  128: `PKGSRC_MKPIE` is only supported by `pkgtools/cwrappers` from the 2017Q3
  129: release on (`USE_CWRAPPERS` in `mk.conf`).
  130: 
  131: ### Packages failing to build
  132: 
  133: A number of packages may fail to build with this option enabled. The failures
  134: are often related to the absence of the `-fPIC` compilation flag when building
  135: libraries or executables (or ideally `-fPIE` in the latter case). This flag is
  136: added to the `CFLAGS` already, but requires the package to actually support it.
  137: 
  138: #### How to fix
  139: 
  140: These instructions are meant as a reference only; they likely need to be adapted
  141: for many packages individually.
  142: 
  143: For packages using `Makefiles`:
  144: 
  145:     MAKE_FLAGS+=	CFLAGS=${CFLAGS:Q}
  146:     MAKE_FLAGS+=	LDFLAGS=${LDFLAGS:Q}
  147: 
  148: For packages using `Imakefiles`:
  149: 
  150:     MAKE_FLAGS+=	CCOPTIONS=${CFLAGS:Q}
  151:     MAKE_FLAGS+=	LOCAL_LDFLAGS=${LDFLAGS:Q}
  152: 
  153: ### Run-time crashes
  154: 
  155: Some programs may fail to run, or crash at random times once built as PIE. Two
  156: scenarios are essentially possible:
  157: 
  158: * actual bug in the program crashing, exposed thanks to ASLR/mprotect;
  159: * bug in the implementation of ASLR/mprotect in the Operating System.
  160: 
  161: ## Problems with `PKGSRC_USE_FORTIFY`
  162: 
  163: ### Packages failing to build
  164: 
  165: This feature makes use of pre-processing directives to look for hardened,
  166: alternative implementations of essential library calls. Some programs may fail
  167: to build as a result; this usually happens for those trying too hard to be
  168: portable, or otherwise abusing definitions in the standard library.
  169: 
  170: This will require a modification to the program, or disabling this feature for
  171: part or all of the build.
  172: 
  173: ### Run-time crashes
  174: 
  175: Just like with `PKGSRC_MKPIE` above, this feature may cause some programs to
  176: crash, usually indicating an actual bug in the program. The fix will typically
  177: involve patching the original program.
  178: 
  179: ### Optimization is required
  180: 
  181: At least in the case of GCC, FORTIFY will only be applied if optimization is
  182: applied while compiling. This means that the CFLAGS should also contain -O, -O2
  183: or another optimization level. This cannot easily be applied globally, as some
  184: packages may require specific optimization levels.
  185: 
  186: ## Problems with `PKGSRC_USE_RELRO`
  187: 
  188: ### Performance impact
  189: 
  190: For better protection, full RELRO requires every symbol to be resolved when the
  191: program starts, rather than simply when required at run-time. This will have
  192: more impact on programs using a lot of symbols, or linked to libraries exposing
  193: a lot of symbols. Therefore, daemons or programs otherwise running in
  194: background are affected only when started. Programs loading plug-ins at
  195: run-time are affected when loading the plug-ins.
  196: 
  197: The impact is not expected to be noticeable on modern hardware, except in some
  198: cases for big programs.
  199: 
  200: ### Run-time crashes
  201: 
  202: Some programs handle plug-ins and dependencies in a way that conflicts with
  203: RELRO: for instance, with an initialization routine listing any other plug-in
  204: required. With full RELRO, the missing symbols are resolved before the
  205: initialization routine can run, and the dynamic loader will not be able to find
  206: them directly and abort as a result. Unfortunately, this is how Xorg loads its
  207: drivers. Partial RELRO can be applied instead in this case.
  208: 
  209: ## Problems with `PKGSRC_USE_SSP`
  210: 
  211: ### Packages failing to build
  212: 
  213: The stack-smashing protection provided by this option does not work for some
  214: programs. The two most common situations in which this happens are:
  215: 
  216: * the program makes use of the `alloca(3)` library call (memory allocator on the
  217:   stack)
  218: * the program allocates variables on the stack, with the size determined at
  219:   run-time.
  220: 
  221: Both cases will require a modification to the program, or disabling this feature
  222: for part or all of the build.
  223: 
  224: ### Run-time crashes
  225: 
  226: Again, this feature may cause some programs to crash, usually indicating an
  227: actual bug in the program. Patching the original program is then required.
  228: 
  229: ### Performance impact
  230: 
  231: The compiler emits extra code when using this feature: a check for buffer
  232: overflows is performed when entering and exiting functions, requiring an extra
  233: variable on the stack. The level of protection can otherwise be adjusted to
  234: affect only those functions considered more sensitive by the compiler (with
  235: `-fstack-protector` instead of `-fstack-protector-all`).
  236: 
  237: The impact is not expected to be noticeable on modern hardware. However,
  238: programs with a hard requirement to run at the fastest possible speed should
  239: avoid using this feature, or using libraries built with this feature.
  240: 
  241: # Auditing the system
  242: 
  243: The illusion of security is worse than having no security at all. This section
  244: lists a number of ways to ensure the security features requested are actually
  245: effective.
  246: 
  247: _These instructions were obtained and tested on a system derived from NetBSD 7
  248: (amd64). YMMV._
  249: 
  250: ## Checking for PIE
  251: 
  252: The ELF executable type in use changes for binaries built as PIE; without:
  253: 
  254:     $ file /path/to/bin/ary
  255:     /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
  256: 
  257: as opposed to the following binary, built as PIE:
  258: 
  259:     $ file /path/to/pie/bin/ary
  260:     /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
  261: 
  262: The latter result is then what is expected.
  263: 
  264: ## Checking for partial RELRO
  265: 
  266: The following command should list a section called `RELRO`:
  267: 
  268:     $ objdump -p /path/to/bin/ary
  269: 
  270:     /path/to/bin/ary:     file format elf64-x86-64
  271: 
  272:     Program Header:
  273:     [...]
  274:        RELRO off    0x0000000000000d78 vaddr 0x0000000000600d78 paddr 0x0000000000600d78 align 2**0
  275: 
  276: This check is now performed automatically if `PKG_DEVELOPER` is set and `RELRO`
  277: is enabled.
  278: 
  279: ## Checking for full RELRO
  280: 
  281: The dynamic loader will apply RELRO immediately when detecting the presence of
  282: the `BIND_NOW` flag:
  283: 
  284:     $ objdump -x /path/to/bin/ary
  285: 
  286:     /path/to/bin/ary:     file format elf64-x86-64
  287: 
  288:     Dynamic Section:
  289:     [...]
  290:       BIND_NOW             0x0000000000000000
  291: 
  292: This has to be combined with partial RELRO (see above) to be fully efficient.
  293: 
  294: ## Checking for SSP
  295: 
  296: Building objects, binaries and libraries with SSP will affect the presence of
  297: additional symbols in the resulting file:
  298: 
  299:     $ nm /path/to/bin/ary
  300:     [...]
  301:                      U __stack_chk_fail
  302:     0000000000600ea0 B __stack_chk_guard
  303: 
  304: This is an indicator that the program was indeed built with support for SSP.
  305: 
  306: This check is now performed automatically (where supported) if `PKG_DEVELOPER`
  307: is set and `SSP` is enabled.

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