Annotation of wikisrc/pkgsrc/hardening.mdwn, revision 1.26

1.1       khorben     1: [[!meta title="Hardening pkgsrc"]]
                      2: 
1.22      gdt         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
1.25      khorben    11: individually described below. They are sorted by whether thery are
1.26    ! khorben    12: enabled by default, and then by their ordering in `mk/defaults/mk.conf`.
1.22      gdt        13: 
1.24      gdt        14: Typically, a feature will cause some programs to fail to build or work
1.25      khorben    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
1.24      gdt        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.
1.23      gdt        23: 
1.22      gdt        24: ## Enabled by default in the stable branch
1.1       khorben    25: 
1.23      gdt        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: 
1.25      khorben    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.
1.23      gdt        34: 
                     35: It has been enabled by default since pkgsrc-2017Q3.
                     36: 
                     37: ### PKGSRC_USE_SSP
1.22      gdt        38: 
1.23      gdt        39: This enables a stack-smashing protection mitigation.
                     40: 
1.25      khorben    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.
1.23      gdt        43: 
                     44: It is enabled by default where known supported since pkgsrc-2017Q3.
1.22      gdt        45: 
                     46: ## Enabled by default in pkgsrc HEAD
                     47: 
                     48: ## Not enabled by default
                     49: 
1.23      gdt        50: ### PKGSRC_MKPIE
                     51: 
                     52: This requests the the creation of PIE (Position Independent
1.25      khorben    53: Executables) for all executables. The PIE mechanism is normally used
1.23      gdt        54: for shared libraries so that they can be loaded at differing addresses
1.25      khorben    55: at runtime. PIE itself does not have useful security properties.
1.23      gdt        56: However, some operating systems support Address Space Layout
                     57: Randomization (ASLR), which causes different addresses to be used each
1.25      khorben    58: time a program is run. This makes it more difficult for an attacker
1.23      gdt        59: to guess addresses and thus makes exploits harder to construct.
                     60: 
                     61: TODO/check: PIE executables will only be built for toolchains that
1.25      khorben    62: support PIE and operating systems known to support ASLR. Currently,
1.23      gdt        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.
1.22      gdt        69: 
1.24      gdt        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: 
1.23      gdt        77: ### PKGSRC_USE_STACK_CHECK
1.22      gdt        78: 
1.23      gdt        79: This uses `-fstack-check` with GCC for another stack protection
                     80: mitigation.
1.1       khorben    81: 
1.2       khorben    82: # Caveats
                     83: 
                     84: ## Problems with `PKGSRC_MKPIE`
                     85: 
1.19      khorben    86: ### Recent support for cwrappers
1.2       khorben    87: 
1.19      khorben    88: `PKGSRC_MKPIE` is only supported by `pkgtools/cwrappers` from the 2017Q3
                     89: release on (`USE_CWRAPPERS` in `mk.conf`).
1.2       khorben    90: 
                     91: ### Packages failing to build
                     92: 
                     93: A number of packages may fail to build with this option enabled. The failures
1.18      khorben    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
1.2       khorben    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: 
1.4       khorben   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: 
1.7       khorben   139: ## Problems with `PKGSRC_USE_RELRO`
                    140: 
                    141: ### Performance impact
                    142: 
                    143: For better protection, full RELRO requires every symbol to be resolved when the
1.11      khorben   144: program starts, rather than simply when required at run-time. This will have
                    145: more impact on programs using a lot of symbols, or linked to libraries exposing
                    146: a lot of symbols. Therefore, daemons or programs otherwise running in
                    147: background are affected only when started. Programs loading plug-ins at
                    148: run-time are affected when loading the plug-ins.
1.7       khorben   149: 
                    150: The impact is not expected to be noticeable on modern hardware, except in some
                    151: cases for big programs.
                    152: 
1.12      khorben   153: ### Run-time crashes
                    154: 
                    155: Some programs handle plug-ins and dependencies in a way that conflicts with
                    156: RELRO: for instance, with an initialization routine listing any other plug-in
                    157: required. With full RELRO, the missing symbols are resolved before the
                    158: initialization routine can run, and the dynamic loader will not be able to find
                    159: them directly and abort as a result. Unfortunately, this is how Xorg loads its
                    160: drivers. Partial RELRO can be applied instead in this case.
                    161: 
1.3       khorben   162: ## Problems with `PKGSRC_USE_SSP`
                    163: 
                    164: ### Packages failing to build
                    165: 
                    166: The stack-smashing protection provided by this option does not work for some
                    167: programs. The two most common situations in which this happens are:
                    168: 
                    169: * the program makes use of the `alloca(3)` library call (memory allocator on the
                    170:   stack)
                    171: * the program allocates variables on the stack, with the size determined at
                    172:   run-time.
                    173: 
                    174: Both cases will require a modification to the program, or disabling this feature
                    175: for part or all of the build.
                    176: 
                    177: ### Run-time crashes
                    178: 
1.4       khorben   179: Again, this feature may cause some programs to crash, usually indicating an
                    180: actual bug in the program. Patching the original program is then required.
1.3       khorben   181: 
1.8       khorben   182: ### Performance impact
                    183: 
                    184: The compiler emits extra code when using this feature: a check for buffer
                    185: overflows is performed when entering and exiting functions, requiring an extra
                    186: variable on the stack. The level of protection can otherwise be adjusted to
                    187: affect only those functions considered more sensitive by the compiler (with
                    188: `-fstack-protector` instead of `-fstack-protector-all`).
                    189: 
                    190: The impact is not expected to be noticeable on modern hardware. However,
                    191: programs with a hard requirement to run at the fastest possible speed should
                    192: avoid using this feature, or using libraries built with this feature.
                    193: 
1.5       khorben   194: # Auditing the system
                    195: 
                    196: The illusion of security is worse than having no security at all. This section
                    197: lists a number of ways to ensure the security features requested are actually
                    198: effective.
                    199: 
                    200: _These instructions were obtained and tested on a system derived from NetBSD 7
                    201: (amd64). YMMV._
                    202: 
                    203: ## Checking for PIE
                    204: 
                    205: The ELF executable type in use changes for binaries built as PIE; without:
                    206: 
                    207:     $ file /path/to/bin/ary
                    208:     /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
                    209: 
                    210: as opposed to the following binary, built as PIE:
                    211: 
                    212:     $ file /path/to/pie/bin/ary
                    213:     /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
                    214: 
                    215: The latter result is then what is expected.
                    216: 
1.13      khorben   217: ## Checking for partial RELRO
1.5       khorben   218: 
                    219: The following command should list a section called `RELRO`:
                    220: 
                    221:     $ objdump -p /path/to/bin/ary
                    222: 
                    223:     /path/to/bin/ary:     file format elf64-x86-64
                    224: 
                    225:     Program Header:
                    226:     [...]
                    227:        RELRO off    0x0000000000000d78 vaddr 0x0000000000600d78 paddr 0x0000000000600d78 align 2**0
1.6       khorben   228: 
1.17      khorben   229: This check is now performed automatically if `PKG_DEVELOPER` is set and `RELRO`
                    230: is enabled.
                    231: 
1.13      khorben   232: ## Checking for full RELRO
                    233: 
                    234: The dynamic loader will apply RELRO immediately when detecting the presence of
                    235: the `BIND_NOW` flag:
                    236: 
                    237:     $ objdump -x /path/to/bin/ary
                    238: 
                    239:     /path/to/bin/ary:     file format elf64-x86-64
                    240: 
                    241:     Dynamic Section:
                    242:     [...]
                    243:       BIND_NOW             0x0000000000000000
                    244: 
                    245: This has to be combined with partial RELRO (see above) to be fully efficient.
                    246: 
1.6       khorben   247: ## Checking for SSP
                    248: 
                    249: Building objects, binaries and libraries with SSP will affect the presence of
                    250: additional symbols in the resulting file:
                    251: 
                    252:     $ nm /path/to/bin/ary
                    253:     [...]
                    254:                      U __stack_chk_fail
                    255:     0000000000600ea0 B __stack_chk_guard
                    256: 
                    257: This is an indicator that the program was indeed built with support for SSP.
                    258: 
1.10      khorben   259: # References
                    260: 
                    261: * <http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html>
                    262: 

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