Annotation of wikisrc/pkgsrc/hardening.mdwn, revision 1.25
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.22 gdt 12: enabled by default, and then by their ordering in mk/defaults/mk.conf.
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
![[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