Annotation of wikisrc/pkgsrc/hardening.mdwn, revision 1.47
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.27 khorben 11: individually described below. They are sorted by whether they 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.39 leot 24: ## Enabled by default
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.47 ! nia 32: Two mitigation levels are available:
1.23 gdt 33:
1.47 ! nia 34: - "weak" only enables checks at compile-time.
! 35: - "strong" enables checks at compile-time and runtime.
! 36:
! 37: `strong` has been enabled by default since pkgsrc-2017Q3.
1.23 gdt 38:
39: ### PKGSRC_USE_SSP
1.22 gdt 40:
1.29 khorben 41: This enables a stack-smashing protection mitigation. It is done by adding a
42: guard variable to functions with vulnerable objects. The guards are initialized
43: when a function is entered and then checked when the function exits. The guard
44: check will fail and the program forcibly exited if the variable was modified in
45: the meantime. This can happen in case of buffer overflows or memory corruption,
46: and therefore exposing these bugs.
47:
1.30 khorben 48: Different mitigation levels are available:
1.34 khorben 49:
1.30 khorben 50: * the default ("yes"), which will only protect functions considered vulnerable
51: by the compiler;
52: * "all", which will protect every function;
53: * "strong", which will apply a better balance between the two settings above.
54:
1.29 khorben 55: This mitigation is supported by both GCC and clang. It may be supported in
56: additional compilers, possibly under a different name. It is particularly useful
57: for unsafe programming languages, such as C/C++.
1.23 gdt 58:
1.29 khorben 59: It is enabled by default where known supported since pkgsrc-2017Q3.
1.23 gdt 60:
1.33 khorben 61: More details can be found here:
1.34 khorben 62:
1.29 khorben 63: * <https://en.wikipedia.org/wiki/Buffer_overflow_protection>
1.22 gdt 64:
65: ## Not enabled by default
66:
1.23 gdt 67: ### PKGSRC_MKPIE
68:
1.36 khorben 69: This requests the creation of PIE (Position Independent Executables) for all
1.37 khorben 70: executables. The PIE mechanism is normally used for shared libraries, so that
1.36 khorben 71: they can be loaded at differing addresses at runtime. PIE itself does not have
1.37 khorben 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.
1.23 gdt 78:
1.31 khorben 79: PIE executables will only be built for toolchains that are known to support PIE.
80: Currently, this means NetBSD on amd64 and i386.
1.23 gdt 81:
1.38 khorben 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:
1.23 gdt 94: ### PKGSRC_USE_RELRO
95:
96: This also makes the exploitation of some security vulnerabilities more
97: difficult in some cases.
1.22 gdt 98:
1.33 khorben 99: Two different mitigation levels are available:
1.34 khorben 100:
1.33 khorben 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.
1.24 gdt 106:
1.33 khorben 107: This is currently supported by GCC. Many software distributions now enable this
108: feature by default, at the "partial" level.
1.24 gdt 109:
1.33 khorben 110: More details can be found here:
1.34 khorben 111:
1.33 khorben 112: * <http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html>
1.24 gdt 113:
1.23 gdt 114: ### PKGSRC_USE_STACK_CHECK
1.22 gdt 115:
1.32 khorben 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.
1.1 khorben 121:
1.2 khorben 122: # Caveats
123:
124: ## Problems with `PKGSRC_MKPIE`
125:
1.19 khorben 126: ### Recent support for cwrappers
1.2 khorben 127:
1.19 khorben 128: `PKGSRC_MKPIE` is only supported by `pkgtools/cwrappers` from the 2017Q3
129: release on (`USE_CWRAPPERS` in `mk.conf`).
1.2 khorben 130:
131: ### Packages failing to build
132:
133: A number of packages may fail to build with this option enabled. The failures
1.18 khorben 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
1.2 khorben 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:
1.4 khorben 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:
1.43 leot 170: This will require a modification to the program, or disabling this feature
171: by adding in the package `Makefile`:
172:
173: FORTIFY_SUPPORTED= no
1.4 khorben 174:
175: ### Run-time crashes
176:
177: Just like with `PKGSRC_MKPIE` above, this feature may cause some programs to
178: crash, usually indicating an actual bug in the program. The fix will typically
179: involve patching the original program.
180:
1.28 khorben 181: ### Optimization is required
182:
183: At least in the case of GCC, FORTIFY will only be applied if optimization is
184: applied while compiling. This means that the CFLAGS should also contain -O, -O2
185: or another optimization level. This cannot easily be applied globally, as some
186: packages may require specific optimization levels.
187:
1.7 khorben 188: ## Problems with `PKGSRC_USE_RELRO`
189:
190: ### Performance impact
191:
192: For better protection, full RELRO requires every symbol to be resolved when the
1.11 khorben 193: program starts, rather than simply when required at run-time. This will have
194: more impact on programs using a lot of symbols, or linked to libraries exposing
195: a lot of symbols. Therefore, daemons or programs otherwise running in
196: background are affected only when started. Programs loading plug-ins at
197: run-time are affected when loading the plug-ins.
1.7 khorben 198:
199: The impact is not expected to be noticeable on modern hardware, except in some
200: cases for big programs.
201:
1.12 khorben 202: ### Run-time crashes
203:
204: Some programs handle plug-ins and dependencies in a way that conflicts with
205: RELRO: for instance, with an initialization routine listing any other plug-in
206: required. With full RELRO, the missing symbols are resolved before the
207: initialization routine can run, and the dynamic loader will not be able to find
208: them directly and abort as a result. Unfortunately, this is how Xorg loads its
209: drivers. Partial RELRO can be applied instead in this case.
210:
1.3 khorben 211: ## Problems with `PKGSRC_USE_SSP`
212:
213: ### Packages failing to build
214:
215: The stack-smashing protection provided by this option does not work for some
1.47 ! nia 216: programs. The most common situation in which this happens is when the program
! 217: allocates variables on the stack, with the size determined at run-time.
1.3 khorben 218:
219: Both cases will require a modification to the program, or disabling this feature
1.42 leot 220: by adding in the package `Makefile`:
221:
222: SSP_SUPPORTED= no
1.3 khorben 223:
224: ### Run-time crashes
225:
1.40 leot 226: Again, this feature may cause some programs to crash via a SIGABRT,
227: usually indicating an actual bug in the program.
228:
229: On NetBSD `LOG_CRIT` level `syslog()` messages are sent and - by
230: default - appended to `/var/log/messages`, e.g.:
231:
1.41 leot 232: Jan 6 15:42:51 <hostname> -: <hostname> <program> - - - buffer overflow detected; terminated
1.40 leot 233:
234: (where `<hostname>` is the `hostname(1)` and `<program>` is the
235: `basename(1)` of the program crashed).
236:
237: Patching the original program is then required.
238:
239: Rebuilding the package via:
240:
241: % env CFLAGS=-g INSTALL_UNSTRIPPED=yes make replace
242:
243: and inspecting the `backtrace` of the coredump via the debugger
244: should point out the problematic call by inspecting the frame
245: calling the `_chk()' (SSP) function.
1.3 khorben 246:
1.8 khorben 247: ### Performance impact
248:
249: The compiler emits extra code when using this feature: a check for buffer
250: overflows is performed when entering and exiting functions, requiring an extra
251: variable on the stack. The level of protection can otherwise be adjusted to
252: affect only those functions considered more sensitive by the compiler (with
253: `-fstack-protector` instead of `-fstack-protector-all`).
254:
255: The impact is not expected to be noticeable on modern hardware. However,
256: programs with a hard requirement to run at the fastest possible speed should
257: avoid using this feature, or using libraries built with this feature.
258:
1.5 khorben 259: # Auditing the system
260:
261: The illusion of security is worse than having no security at all. This section
262: lists a number of ways to ensure the security features requested are actually
263: effective.
264:
265: _These instructions were obtained and tested on a system derived from NetBSD 7
266: (amd64). YMMV._
267:
268: ## Checking for PIE
269:
270: The ELF executable type in use changes for binaries built as PIE; without:
271:
272: $ file /path/to/bin/ary
273: /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
274:
275: as opposed to the following binary, built as PIE:
276:
277: $ file /path/to/pie/bin/ary
278: /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
279:
280: The latter result is then what is expected.
281:
1.13 khorben 282: ## Checking for partial RELRO
1.5 khorben 283:
284: The following command should list a section called `RELRO`:
285:
286: $ objdump -p /path/to/bin/ary
287:
288: /path/to/bin/ary: file format elf64-x86-64
289:
290: Program Header:
291: [...]
292: RELRO off 0x0000000000000d78 vaddr 0x0000000000600d78 paddr 0x0000000000600d78 align 2**0
1.6 khorben 293:
1.17 khorben 294: This check is now performed automatically if `PKG_DEVELOPER` is set and `RELRO`
295: is enabled.
296:
1.13 khorben 297: ## Checking for full RELRO
298:
299: The dynamic loader will apply RELRO immediately when detecting the presence of
300: the `BIND_NOW` flag:
301:
302: $ objdump -x /path/to/bin/ary
303:
304: /path/to/bin/ary: file format elf64-x86-64
305:
306: Dynamic Section:
307: [...]
308: BIND_NOW 0x0000000000000000
309:
310: This has to be combined with partial RELRO (see above) to be fully efficient.
311:
1.6 khorben 312: ## Checking for SSP
313:
314: Building objects, binaries and libraries with SSP will affect the presence of
315: additional symbols in the resulting file:
316:
317: $ nm /path/to/bin/ary
318: [...]
319: U __stack_chk_fail
320: 0000000000600ea0 B __stack_chk_guard
321:
322: This is an indicator that the program was indeed built with support for SSP.
1.35 khorben 323:
324: This check is now performed automatically (where supported) if `PKG_DEVELOPER`
325: is set and `SSP` is enabled.
1.45 leot 326:
327: If it is needed to disable SSP check per-package, please add in the package
328: `Makefile`:
329:
330: CHECK_SSP_SUPPORTED= no
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb
![[BACK]](/icons/back.gif){kind=icon}
Return to hardening.mdwn CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [NetBSD Developer Wiki] / wikisrc / pkgsrc