1 |
Hello, I recently completed the development and testing for an |
2 |
implementation of SSP utilizing frandom as previously discussed on this |
3 |
list. It was a complete success, and I'm pleased to offer it up to |
4 |
everyone interested. |
5 |
|
6 |
Here is the bugzilla link with all the necessary files and instructions: |
7 |
http://bugs.gentoo.org/show_bug.cgi?id=50864 |
8 |
|
9 |
To save everyone a step, here is the main portion of the docs: |
10 |
|
11 |
Firstly, my development server is running 2.6.5-wolk3.0-rc2. It was |
12 |
necessary to rework the frandom kernel patch for this kernel version. The |
13 |
patch is attached and has also been submitted to the frandom author. For |
14 |
2.4 kernels, the included patch should work fine. |
15 |
|
16 |
The ssp-v6.c is based on Ned's (solar's) ssp5.c. I made only the change of |
17 |
including config.h and sysctl.h. Also, I changed the ifdef's to |
18 |
HAVE_DEV_ERANDOM. Finally, I merged the one small cosmetic change from |
19 |
glibc-2.3.3_pre20040117-signal-ssp.diff (this patch is now obsolete). |
20 |
|
21 |
The attached glibc-2.3.2-propolice-guard-functions-v3.patch is simply the |
22 |
v2 version with the ssp.c portion removed. The ssp.c is copied from files/ |
23 |
in the ebuild now to allow for easy changes. This was requested by Ned. |
24 |
|
25 |
The only major change is the attached glibc-2.3.3-frandom-detect.patch. |
26 |
This patches glibc's configure.in to detect the existance of /dev/erandom |
27 |
and use it for SSP functionality. |
28 |
|
29 |
I'm not positive this is the best method for detection. We don't want |
30 |
ssp.c to have to execute multiple open()'s on each exec, so a compile-time |
31 |
implementation seems necessary. I'm not sure merely checking for the |
32 |
existance of /dev/erandom is the best method to detect. Furthermore, the |
33 |
Linux kernel team seems to feel frandom/erandom should be implemented at |
34 |
the user level. The beauty of erandom is that it seeds itself once (from |
35 |
frandom) and does not use any more kernel entropy for subsequent calls. A |
36 |
user level implementation would require a background process to manage a |
37 |
persistent random pool that seeds itself only when necessary. This seems |
38 |
like it's going too far for a glibc patch. Finally, I am considering |
39 |
removing the sysctl pieces from ssp.c, because they are not needed, and a |
40 |
/dev interface is more portable. This topic needs to stay open for |
41 |
discussion. |
42 |
|
43 |
I have also attached a tar.gz of the portage directory. This is intended |
44 |
to act as an overlay directory. You can untar it in /usr/local/portage or |
45 |
something. I apologize for reworking the glibc ebuild, but it was just too |
46 |
confusing. I went through all the patches and files in the files/ |
47 |
directory and took out only what was needed for this branch update ebuild. |
48 |
I moved all these patches into files/2.3.3 and reworked the ebuild to |
49 |
reflect the proper version. This is a suggestion for clean-up, but mostly |
50 |
it's just so I could test and develop more easily. |
51 |
|
52 |
Please let me know how this works for you. |
53 |
|
54 |
Thanks, |
55 |
Cory Visi |
56 |
|
57 |
-- |
58 |
gentoo-hardened@g.o mailing list |