1 |
> So, what is the right way to add SSP to everything (including the kernel) |
2 |
> for Gentoo with a 2.6.7+ kernel, without adding Pax ASLR? |
3 |
|
4 |
ssp and ASLR are different animals, you can use one independently of |
5 |
the other. adding ssp should be automatic when you have a gcc emerged |
6 |
with the hardened USE flag, adding it to the kernel is pointless as |
7 |
things stand now (maybe pappy has more info on how our suggestions |
8 |
to Mr. Etoh progressed since). |
9 |
|
10 |
> The last time I tried a full Gentoo system with ASLR enabled (several |
11 |
> months ago), gdb didn't work on PHP .. a big problem for me. |
12 |
|
13 |
are you sure it wasn't caused by the non-exec page enforcement instead |
14 |
(which prevents gdb from setting breakpoints)? |
15 |
|
16 |
> So the code segments for the shared libraries really are shared when |
17 |
> using 2.6.x with Pax ASLR? |
18 |
|
19 |
it's all independent of PaX or the kernel version, what really matters is |
20 |
whether the shared libs have text relocations or not. normally compiling |
21 |
with -fPIC ensures that they do not, but there are some special libs that |
22 |
for one reason or another contain assembly code and/or are improperly |
23 |
compiled and end up with text relocations. the hardened gentoo subproject |
24 |
is actually trying to get rid of these so that a PaX feature can be enabled |
25 |
that forbids text relocations from the kernel itself (this is because text |
26 |
relocations are a way to generate code at runtime and hence a potential |
27 |
exploit method). |
28 |
|
29 |
> If prelink brings so little memory savings over Pax ASLR, then why would |
30 |
> anyone want to use prelink instead of Pax ASLR on a server? |
31 |
|
32 |
they solve different problems, prelink speeds up runtime linking, it has |
33 |
nothing/little to do with saving memory. ASLR randomizes the address |
34 |
space layout to make certain exploits fail with a high probability. |
35 |
most likely on a server you want every bit of security vs. the small |
36 |
speedup in application startup time. |
37 |
|
38 |
> Prelink also can only randomize the start address of shared libraries, |
39 |
|
40 |
that's not the same kind of randomization as ASLR, it is not per execution |
41 |
but 'whenever you run prelink'. for this reason it's a pretty pointless |
42 |
feature in prelink (considering how people are running prelink from the |
43 |
daily cron, you have more than enough time to brute force the entropy). |
44 |
|
45 |
> not the code segment for the binary in question - unlink ASLR, right? |
46 |
|
47 |
well, i think it depends on the kind of executables you have, probably |
48 |
PIEs can also be prelinked, although i never checked/tried myself. PIEs |
49 |
are the ET_DYN ELF executables that are easiest to randomize and what you |
50 |
also get in hardened gentoo by default. ASLR can also randomize the more |
51 |
traditional ET_EXEC ELF executables but that feature has drawbacks and |
52 |
we're not encouraging its use, but it serves as a good proof-of-concept. |
53 |
|
54 |
|
55 |
-- |
56 |
gentoo-hardened@g.o mailing list |