1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
|
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="pie-ssp.xml">
<title>Gentoo Linux PIE-SSP Documentation</title>
<author title="Author">
<mail link="pappy@gentoo.org">Alexander Gabert</mail>
</author>
<author title="Contributor">
<mail link="solar@gentoo.org">solar</mail>
</author>
<abstract>(This DOC is badly outdated and mostly obsolete) This introductionary guide explains the basic behaviour of the hardened toolchain.</abstract>
<version>1.45</version>
<date>20050805</date>
<chapter>
<title>Introduction to Randomization and Stack Protection</title>
<section>
<body>
<p>
First of all, the PaX homepage has moved to http://pax.grsecurity.net,
please update your bookmarks.
</p>
<p>
While the goal of the PaX suite has remained the same ever since,
preventing memory related security vulnerabilities, there has been major
advancements in the progress of getting similar and coexisting kernel
patches into the attention of the wide public.
</p>
<p>
Even though linear stack smashing attacks, formatstring overflows and
return to libc style attacks cannot be fully prevented or suppressed by
effective randomization of the running executable, there seems to be a
wide consent amongst information security experts and GNU/Linux
distributions that it does help putting up another barrier (see chapter
3).
</p>
<p>
The outstanding support and help from the Gentoo toolchain main developer
and coordinator, Martin Schlemmer as well as Dr. Hiroaki Etoh and moid
from the OpenBSD team with the closer integration of the SSP patch into
the Gentoo toolchain and userland has proven the common goals and
commitments between developers throughout the world striving for better
support and acceptance of technology that provides a security oriented,
high quality, automatic response to simple linear stack overflow attempts.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Kernels with PaX patches</title>
<section>
<body>
<p>
The positive feedback generated by users who are enhanced by the
grsecurity patch being included as a standard security measure in the
native gentoo-sources leads us to uphold the support for grsecurity in
this common practice kernel.
</p>
<p>
While the hardened-sources has been abolished in favour of the ongoing
concurrent development of fully supported MAC/ACL schemes in Gentoo
Hardened, selinux-sources and grsec-sources can benefit from the thorough
implementation of a true PIE (position independent executables) and SSP
(stack smashing protector) environment via the incorporated PaX patch.
</p>
<p>
Chris Pebenito holds up the high quality and standard of the
selinux-sources while keeping in touch with the PaX developments and
introducing randomization and userland features of PIE and SSP via PaX or
correlating patches according to the requirements of the solutions needed
by our partners.
</p>
<p>
The hardened-sources are maintained by hardened team and is the ideal
kernel to use with a hardened toolchain.
</p>
</body>
</section>
</chapter>
<chapter>
<title>GNU C Compiler and the history of PIE support</title>
<section>
<body>
<p>
As described in the introduction, in the last year we have seen major
advancements (and confusion) in the GNU upstream toolchain regarding the
implementation of a system wide scenario for storing information about
stack protection requirements and randomization of executables via PIE
(position independent executables) support.
</p>
<p>
When the first PaX randomization patches came out, a modification to the
GNU C compiler specs file was needed to create so-called
"shared executables".
</p>
<p>
This means that these days the linker was told to explicitly link -fPIC
(gcc function to force the creation of position independent code) compiled
.o object files with a interp.o interpreter field pointing to "/lib/ld.so"
from glibc on the intel platform, using a special custom formed crt1S.o
which was able to set up the addresses of "_main", "_init" (recent glibc:
"__libc_csu_init") and "_fini" (recent glibc: "__libc_csu_fini") in the
"_start" function in a position independent manner.
</p>
<p>
So basically a setup like in a shared library was used to set up the PIC
(position independent code) addressing of the data and the code segments
in the executable that needs to be started via the main() function.
</p>
<p>
There has been a bug on nonintel arches regarding the setup of the PIC
register (%r19 on parisc) for statically linked binaries.
Since this bug has been fixed on all arches we can support, it is now also
safe to create this library-like PIC setup for statically compiled
binaries.
</p>
<p>
When Ingo Molnar from Redhat started to introduce the execshield kernel
patches, the developers at Redhat also wanted to make use of the "hot and
new" randomization for binaries, so Jakub Jelinek invested a lot of time
in the preparation of the toolchain (binutils, glibc, gcc) to introduce
the -pie flag which generates these binaries with the correct interpreter
and a glibc provided Scrt1.o.
</p>
<p>
With Russell Coker involved in the Fedora distribution of Redhat, the
future directions to an Execshield based selinux setup with -pie support
from the toolchain are a visible example for the integration of security
improvements in a full-scale commercial office and home user distribution.
</p>
<p>
Russell Coker also seems to be interested in supporting selinux for
Debian.
</p>
<p>
However, the technical approach to support compatibility needs of
applications (java apps, gcc heuristically sets executable stack for
nested functions) over default security measures (as implemented in PaX
kernels) may not suit environments with higher risk analysis and threat
potential.
</p>
</body>
</section>
</chapter>
<chapter>
<title>A proven gcc extension for linear stack overflow protection</title>
<section>
<body>
<p>
When the OpenBSD team discovered SSP as their favourite utility to limit
the possibility of linear stack overflows, they also evaluated the stack
smash handler functions and found out that the best way to introduce SSP
into their toolchain was a modification of the dynamic linker for
executables requiring that no standard libraries were included (boot
loaders!) and giving all other dynamically linked applications the chance
to retrieve the guard object and the necessary related functions via their
standard C library.
Thus, the dynamically linked executables and shared libraries protected
via propolice were using one exact shared copy of the __guard reference
and the needed functions for setup and smash handling in a single
location.
</p>
<p>
Statically linked executables will have their own copy of __guard and the
functions to work properly.
</p>
<p>
On the Linux platform, Dr. Etoh decided to put the __guard, the
__guard_setup and the __stack_smash_handler into the libgcc of the gcc
package.
This led to problems with big packages like apache2 and mod_php4 producing
false positives because the wrong local __guard copies in shared libraries
and/or the main executable were used by different __stack_smash_handlers,
this odd momentum has been resolved and isolated in gdb sessions by pipacs
from the PaX team.
</p>
<p>
Having moid from the OpenBSD team to help us mitigating this negative side
effect of the GNU C compiler and working close together with Dr. Etoh from
the IBM labs in japan gave us the chance to introduce the first
glibc-based SSP setup for userland in GNU/Linux for Gentoo-Linux at all!
( PIE-SSP it works! )
</p>
</body>
</section>
</chapter>
<chapter>
<title>Position Independent Executables with Propolice support</title>
<section>
<body>
<p>On a Gentoo system this is currently accomplished by merging <c>gcc</c>: </p>
<pre caption="Emerging gcc">
# <i>USE="hardened pic" emerge sys-devel/gcc</i>
</pre>
<p>While a hardened <c>gcc</c> starts the transparent conversion of a system to position independence for your binaries via making use of gcc spec file handling.</p>
<p>Once the gcc has been equipped with that new specs file, a package or a kernel building can only return to the conventional building behaviour when it feeds the correct CFLAGS and LDFLAGS to the build process.</p>
<p>As an example lets try the rebuilding our chpax binary as a position independent
executable. We can use the file(1) command to determine if we
in fact we are building our executables as ET_EXEC or ET_DYN.</p>
<p>The first example here we have chpax built as a ET_DYN
and the second one is chpax not built as a standard ET_EXEC file.</p>
<pre caption="Example files">
# <i>file /sbin/chpax</i>
/sbin/chpax: ELF 32-bit LSB shared object, Intel 80386, version 1 \
(GNU/Linux), stripped
# <i>file /sbin/chpax</i>
/sbin/chpax: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for \
GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
</pre>
<p>The <c>gcc</c> package has been designed to easily revert back to a conventional building environment behaviour in case of problems.</p>
<p>Users can restore the original gcc specs file behaviour at any time by calling the gcc-config utility on the commandline. gcc-config -l ; gcc-config</p>
<p>Ebuilds that experience problems with the a hardened gcc automatic transparency can evaluate the existence of the hardened gcc package on the target system and use compatibility CFLAGS to restore the original gcc behaviour during the emerge.</p>
</body>
</section>
</chapter>
<chapter>
<title>Using distcc with hgcc</title>
<section>
<body>
<p>
<mail link="lisa@gentoo.org">Lisa Marie Seelye</mail> says you need the same hgcc and gcc versions on all distcc host volunteer machines.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Credits and Reference</title>
<section>
<body>
<ul>
<li><uri link="http://pax.grsecurity.net">PaX Homepage</uri></li>
<li><uri link="http://pax.grsecurity.net/docs/index.html">PaX Documentation</uri></li>
<li><uri link="http://www.research.ibm.com/trl/projects/security/ssp/">Propolice/SSP Homepage</uri></li>
<li><uri link="http://www.grsecurity.net">Grsecurity Homepage</uri></li>
<li><uri link="http://fedora.redhat.com">Fedora Homepage</uri></li>
<li><uri link="http://www.openbsd.com">OpenBSD Homepage</uri></li>
<li><uri link="http://www.nsa.gov/selinux">SElinux Homepage</uri></li>
<li><uri link="/doc/en/distcc.xml">Gentoo Distcc Documentation</uri></li>
</ul>
</body>
</section>
</chapter>
</guide>
|
GitWeb