Annotation of wikisrc/pkgsrc/hardening.mdwn, revision 1.23
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
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:
1.23 ! gdt 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:
1.22 gdt 18: ## Enabled by default in the stable branch
1.1 khorben 19:
1.23 ! gdt 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
1.22 gdt 32:
1.23 ! gdt 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.
1.22 gdt 39:
40: ## Enabled by default in pkgsrc HEAD
41:
42: ## Not enabled by default
43:
1.23 ! gdt 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.
1.22 gdt 63:
1.23 ! gdt 64: ### PKGSRC_USE_STACK_CHECK
1.22 gdt 65:
1.23 ! gdt 66: This uses `-fstack-check` with GCC for another stack protection
! 67: mitigation.
1.1 khorben 68:
1.2 khorben 69: # Caveats
70:
71: ## Problems with `PKGSRC_MKPIE`
72:
1.19 khorben 73: ### Recent support for cwrappers
1.2 khorben 74:
1.19 khorben 75: `PKGSRC_MKPIE` is only supported by `pkgtools/cwrappers` from the 2017Q3
76: release on (`USE_CWRAPPERS` in `mk.conf`).
1.2 khorben 77:
78: ### Packages failing to build
79:
80: A number of packages may fail to build with this option enabled. The failures
1.18 khorben 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
1.2 khorben 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:
1.4 khorben 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:
1.7 khorben 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
1.11 khorben 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.
1.7 khorben 136:
137: The impact is not expected to be noticeable on modern hardware, except in some
138: cases for big programs.
139:
1.12 khorben 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:
1.3 khorben 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:
1.4 khorben 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.
1.3 khorben 168:
1.8 khorben 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:
1.5 khorben 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:
1.13 khorben 204: ## Checking for partial RELRO
1.5 khorben 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
1.6 khorben 215:
1.17 khorben 216: This check is now performed automatically if `PKG_DEVELOPER` is set and `RELRO`
217: is enabled.
218:
1.13 khorben 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:
1.6 khorben 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:
1.10 khorben 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