| 1 |
I have attached two patches, they both depend on this one: |
| 2 |
http://www.linuxfromscratch.org/patches/downloads/linux/ |
| 3 |
linux-2.4.26-frandom-1.patch |
| 4 |
|
| 5 |
Here is my new logic for __guard_setup: |
| 6 |
|
| 7 |
This glibc ssp patch tries to use sysctl random_erandom first. If that fails |
| 8 |
it will fall back on libarc4random. Arc4random first tries to open /dev/ |
| 9 |
erandom, if that fails it tries sysctl random_erandom; I know this is being |
| 10 |
done twice, but the delay caused by checking again will add to the entropy |
| 11 |
since this is called 8 times to fill the elements of __guard. /dev/erandom |
| 12 |
can still work if frandom was built as a module, sysctl only works built in. |
| 13 |
If that fails /dev/urandom is checked, if that fails sysctl random_uuid is |
| 14 |
checked. No matter the case, in libarc4random, gettimofday and getpid are |
| 15 |
used in the stir. In the event you run a program inside a chroot, with a |
| 16 |
grsec kernel, without the frandom patch, and without urandom in the chroot, |
| 17 |
this is the conditions that gettimeofday+getpid are only used for the stir. |
| 18 |
Random_uuid is read only by root in a grsec kernel. This entropy is run threw |
| 19 |
the arcfour stream cipher and returns 65536 byte strings for __guard[i]. If |
| 20 |
arc4random fails, and it shouldn't, ssp will still fallback on the terminator |
| 21 |
canary. |
| 22 |
|
| 23 |
The arc4random patch installs a header that can be used by other software. If |
| 24 |
the system is running sysctl erandom the only fallback that will be checked |
| 25 |
is the final one, with the terminator canary. Its about 8 syscalls to fill |
| 26 |
the __guard array. If all the fallbacks are used its about 30 syscalls, if |
| 27 |
erandom and urandom are missing and sysctl doesn't work. Durring normal |
| 28 |
operation with sysctl erandom it should work smoothly. |
Archives