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