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
|
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/proj/en/hardened/primer.xml">
<title>Introduction to Hardened Gentoo</title>
<author title="Author">
<mail link="method@gentoo.org">Joshua Brindle</mail>
</author>
<author title="Contributor">
<mail link="tocharian@gentoo.org">Adam Mondl</mail>
</author>
<author title="Editor">
<mail link="solar@gentoo.org">Ned Ludd</mail>
</author>
<abstract>A Primer on Hardened Gentoo.</abstract>
<version>1.2</version>
<date>2007-02-07</date>
<chapter>
<title>Introduction</title>
<section>
<body>
<p>
This guide is meant for anyone unsure about the offerings of the
Hardened Gentoo project, how to use them together, and what their
respective roles in the project are.
</p>
<p>
The basic security principle that we emphasize is layers of security.
Layers are fundamental in ensuring a users machine is not compromised,
and if it is, minimizing the damages done. By combining a series of
dissimilar, though security related technologies, we make an attacker
jump through additional hoops before a compromise may occur. For this
reason we always recommended that you decide what your specific needs
are and combine those solutions to protect your system. We will try to
explain the options and how they can be used together in this
document.
</p>
<p>
Hardened Gentoo is not a product or solution in itself, it is merely a
project with a group of developers all working toward the same goal of
very proactive security. The sub-projects contained in Hardened Gentoo
aren't related in any more way than they are hosted within the same
project. You might think of it as the same way KDE and GNOME are both
part of the desktop project, and both have a common goal but are
otherwise unrelated to each other.
</p>
<note>
Asking for help installing or support of your 'Hardened Gentoo' machine
is not clear and should always be clarified by saying you have a
SELinux problem, PIE/SSP problem, and so on.
</note>
</body>
</section>
</chapter>
<chapter>
<title>Technologies Offered</title>
<section>
<title>PaX</title>
<body>
<p>
At the heart of the project is PaX. PaX is a kernel patch
that allows you to protect against buffer and heap overflows and
similar attacks. PaX is your first line of defense.
</p>
<p>Because of badly
written software you are always at risk of a compromise because of
buffer and heap overflows. Buffer and Heap overflows are the result of
unchecked bounds in user input in applications. When an attacker has
the ability to give input to an application that is inserted into
memory but not checked there exists the possibility of an overflow.
Lower level programming languages like C and C++ do not automatically
protect from overruns, and the end result is that when a buffer is
overrun adjacent executable code can be overwritten with input from the
user. This would normally cause the application to crash if the users
input isn't understood by the machine. This generally manifests itself
as a page fault because the characters that overrun the buffer into the
executable area will be treated as an address which probably won't
exist. This is the most benign result of an overrun.
</p>
<p>If the attacker
knows of an overrun, however, they will have the opportunity to add
shellcode to the input and rather than causing the application to crash
it will instead execute the instructions they give. This is done
because shellcode is how instructions are stored in memory for
execution by the processor. Basically shellcode consists of 'opcodes'
which translate to assembly routines. An attacker knows these opcodes
very well and can create shellcode which allows them to do anything
they desire, such as run a root shell and bind it to a port. When this
happens the user won't even be aware that it has because the
application doesn't crash, instead it starts executing the attackers
arbitrary code allowing them to do anything they please. PaX mitigates
this problem by randomly placing each function and buffer in an
application in memory. This is called ASLR or Address Space Layout
Randomization and is the cornerstone of PaX By having random offsets
for functions and buffers the attacker is unable to craft an input
which will guarantee that the shellcode will be executed (and makes it
very difficult since the application will probably crash and be
restarted with new random offsets). ASLR is most useful when used with
PIE (position independent executable) code but also works with standard
executable code, at the cost of overhead.
</p>
<p>PaX also offers the ability
for executable segments to be executable and not writable, and likewise
writable segments to be writable and not executable. This is called
pageexec. On x86 based processors there is no ability to do this on a
hardware level since the x86 designers collapsed the read and execute
memory flags into 1 to save space. Since a page can either be writable
or readable and executable it is not useful to set buffers as
non-executable since they would no longer be readable. So on x86 PaX
emulates this behavior at a software level, which introduces overhead
but is very helpful for security.
</p>
</body>
</section>
<section>
<title>PIE/SSP</title>
<body>
<p>
In the interest of clarity, while PIE and SSP are generally grouped in
discussion because they are both part of the hardened toolchain, they
are indeed different technologies with different purposes. PIE by itself
provides no additional security, but when combined with PaX in the kernel
provides a powerful tool against overflows. SSP is entirely implemented
in userland and protects against stack smashing attacks without the
assistance of the kernel. Since these are implemented separately and do
different things they are indeed 2 different layers of protection, for
example, one attack that might get past PaX, called ret2libc, would be
blocked by SSP.
</p>
<p>
We have gone through great lengths to provide users with an easy way to
build the entire userland with PIE code as to take advantage of ASLR
with very little overhead. In addition to PIE our 'hardened' toolchain
also provides SSP or stack smashing protection. SSP protects against
stack smashing by allocating an area outside of buffers and putting a
random, cryptographic canary (or marker) in it. This allows SSP to check
whether the canary was overwritten after any write to the buffer and
allows it to kill the app if it was overwritten. The hardened toolchain
gives users a PIE/SSP userland the easiest possible way. Stages marked
with 'hardened' are standard stages built with PIE and SSP, they do not
include SELinux/RSBAC/grsecurity access controls.
</p>
</body>
</section>
<section>
<title>Mandatory Access Control</title>
<body>
<p>
While PaX is the first layer of protection, perhaps even the second or
third if you have firewalls and/or network intrusion detection, it is
also recommended that you use access control to further secure your system.
It is very important that you realize access control as your <b>last</b>
layer of protection. Access control is very helpful to contain attackers
which already got access to your system, or local users. Currently
Hardened Gentoo supports 3 access control solutions: SELinux,
grsecurity, and RSBAC.
</p>
<p>
If you wish to use grsecurity you need not worry about which stages to use as grsecurity
requires no userland changes. Simply use the hardened stages and once you are
ready to build a kernel use a grsecurity-enabled kernel such as
hardened-sources. Once your system is up and running you can use
grsecurity's learning mode to build ACL's for your system.
</p>
<p>
Similar to grsecurity, RSBAC does not require any userland changes but can be
installed after setting up a normal Gentoo installation. RSBAC is supported by
the rsbac-sources kernel. Once your system is running you
can then choose from the different access control models offered by RSBAC
since they are all modules. The RSBAC Gentoo documentation lists the various models
offered and provides more information about each one.
</p>
<p>
So we've talked about 2 layers that we offer, we have intentions to offer more
and will in the future. Examples of additional layers are intrusion
detection/prevention, which would be first even before PaX.
Encrypted disks and swap which offer protection from 'physical' security
breaches. Auditing, which would allow you to see and act upon risks before
they become a compromise. Encrypted network traffic and strong authentication
are also layers which are very supported in mainline Linux installations and
probably won't be focused upon here.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Resources</title>
<section>
<body>
<table>
<tr>
<th>
Project
</th>
<th>
Project homepage
</th>
<th>
Gentoo project page
</th>
</tr>
<tr>
<ti>
PaX
</ti>
<ti>
<uri link="http://pax.grsecurity.net">http://pax.grsecurity.net</uri>
</ti>
<ti>
<uri link="http://hardened.gentoo.org/pax-quickstart.xml">http://hardened.gentoo.org/pax-quickstart.xml</uri>
</ti>
</tr>
<tr>
<ti>
PIE
</ti>
<ti>
Not Available
</ti>
<ti>
Not Available
</ti>
</tr>
<tr>
<ti>
SSP
</ti>
<ti>
<uri link="http://www.trl.ibm.com/projects/security/ssp/">http://www.trl.ibm.com/projects/security/ssp/</uri>
</ti>
<ti>
Not available
</ti>
</tr>
<tr>
<ti>
SELinux
</ti>
<ti>
<uri link="http://www.nsa.gov/selinux">http://www.nsa.gov/selinux</uri>
</ti>
<ti>
<uri link="http://hardened.gentoo.org/selinux">http://hardened.gentoo.org/selinux</uri>
</ti>
</tr>
<tr>
<ti>
grsecurity
</ti>
<ti>
<uri link="http://www.grsecurity.net">http://www.grsecurity.net</uri>
</ti>
<ti>
<uri link="http://hardened.gentoo.org/grsecurity.xml">http://hardened.gentoo.org/grsecurity.xml</uri>
</ti>
</tr>
</table>
</body>
</section>
</chapter>
</guide>
|
GitWeb