This is a working implementation of the frandom/SSP code as discussed on the gentoo-hardened mailing list for Gentoo's glibc. This implementation is currently running on my development server successfully. Firstly, my development server is running 2.6.5-wolk3.0-rc2. It was necessary to rework the frandom kernel patch for this kernel version. The patch is attached and has also been submitted to the frandom author: Eli Billauer <contact@billauer.co.il> http://www.billauer.co.il/frandom.html For 2.4 kernels, the included patch should work fine. The ssp-v6.c is based on Ned's (solar's) ssp5.c. I made only the change of including config.h and sysctl.h. Also, I changed the ifdef's to HAVE_DEV_ERANDOM. Finally, I merged the one small cosmetic change from glibc-2.3.3_pre20040117-signal-ssp.diff (this patch is now obsolete). The attached glibc-2.3.2-propolice-guard-functions-v3.patch is simply the v2 version with the ssp.c portion removed. The ssp.c is copied from files/ in the ebuild now to allow for easy changes. This was requested by Ned. The only major change is the attached glibc-2.3.3-frandom-detect.patch. This patches glibc's configure.in to detect the existance of /dev/erandom and use it for SSP functionality. I'm not positive this is the best method for detection. We don't want ssp.c to have to execute multiple open()'s on each exec, so a compile-time implementation seems necessary. I'm not sure merely checking for the existance of /dev/erandom is the best method to detect. Furthermore, the Linux kernel team seems to feel frandom/erandom should be implemented at the user level. The beauty of erandom is that it seeds itself once (from frandom) and does not use any more kernel entropy for subsequent calls. A user level implementation would require a background process to manage a persistent random pool that seeds itself only when necessary. This seems like it's going too far for a glibc patch. Finally, I am considering removing the sysctl pieces from ssp.c, because they are not needed, and a /dev interface is more portable. This topic needs to stay open for discussion. I have also attached a tar.gz of the portage directory. This is intended to act as an overlay directory. You can untar it in /usr/local/portage or something. I apologize for reworking the glibc ebuild, but it was just too confusing. I went through all the patches and files in the files/ directory and took out only what was needed for this branch update ebuild. I moved all these patches into files/2.3.3 and reworked the ebuild to reflect the proper version. This is a suggestion for clean-up, but mostly it's just so I could test and develop more easily.
Created attachment 31277 [details] frandom-0.8-linux-2.6.patch
Created attachment 31278 [details] glibc-2.3.3_pre20040420.ebuild
Created attachment 31279 [details, diff] glibc-2.3.2-propolice-guard-functions-v3.patch
Created attachment 31280 [details, diff] glibc-2.3.3-frandom-detect.patch
Created attachment 31281 [details, diff] ssp-v6.c
Created attachment 31282 [details] glibc-2.3.3_pre20040420.tgz
I should mention that I tested this on a development machine that was previously starving for entropy. Even with a healthy audio-entropyd and mic setup. After merely emerging this new glibc, my entropy immediately began increasing steadily and after about 10 mins., reached the maximum poolsize. Nice idea Robert!
Great and thanks. I'm thinking here that we should maybe have a USE flag also for the erandom detection. logic is as follows use erandom || myconf=--disable && myconf=--enable This way erandom/frandom can be placed in out baselayout as not everybody will want to run devfsd/udev. Now next thing ;/ I've been in binutils-2.15 land for a while now which pukes every time while building a glibc. I'll switch out to a older binutils and give this all a shot. Also reassigning bug to toolchain@
ok I think I solved the binutils + new glibc bug I had mentioned. Getting a patch put together will just take a bit of time. If your interested in helping there the trick is to disable ASLR in the compiled ld.so ( chpax/paxctl -r ) then remove the bits after it does it locale stuff. Better solution would be to hunt down the problem in dl_main() with it trying to exec code at %eip 0x00000000 I think in reality I wont be able to test this stuff to later tonight to tmw.
Till then are we ok with USE= erandom ?
Ok I've taken a nice close look at this and I don't think I can merge it as is. I'd like to suggest some changes. 1) leave the orig comments intact. 2) Try to leave the hardcoded 2.3.3/ intact vs the ${REAL_PV} (makes it clearer for us to maintain) 3) Lets drop the +SSP_V="v6" (files/2.3.3/ssp.c is fine) 4) Add your name to the ssp.c 5) Consider adding erandom to IUSE 6) Consider change in ssp.c from HAVE_ to WANT_
Created attachment 31434 [details] glibc-2.3.3_pre20040420-r1.ebuild Ned, I used all your suggestions except the HAVE/WANT change. Let me know if you need anything else. "erandom" should be added as a local use flag.
Created attachment 31435 [details] ssp.c
i patched this to compile properly with gcc 3.4, but for some reason the exact same fix isnt working for the ssp.c in glibc-2.3.3_pre20040420... i'm pretty confused here. anyways, the gcc 3.4 fix is in CVS and simply involves marking __guard_setup with the used attribute and default visibility attribute. no idea why this doesnt work with the old ssp.c... any input would be greatly appreciated.
Created attachment 32075 [details] glibc-2.3.2-r10.ebuild Backport to the current stable version of glibc. Tested for compile/install on x86. It was not necessary to alter the patches (glibc-2.3.3-frandom-detect.patch, glibc-2.3.2-propolice-guard-functions-v3.patch, ssp.c) in any way; they can be re-used for this version.
I want to get this into the tree. I've just been lacking time to confirm it builds. Any other devs can do a trial run and test? (pretty please)
well, i hopped into chroot to test this and it works fine on amd64 with hardened gcc 3.3.3-r5: ayanami / # /lib/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.3 20040412 (Gentoo Hardened Linux 3.3.3-r5, ssp-3.3-7, pie-8.7.5.3). Compiled on a Linux 2.4.21 system on 2004-06-02. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bugs@gnu.org>. ayanami / # readelf -s /lib/libc.so.6 | grep guard 695: 0000000000233088 8 OBJECT GLOBAL DEFAULT 27 __guard@@GLIBC_2.3.2 851: 000000000001dac0 141 FUNC GLOBAL DEFAULT 11 __guard_setup@@GLIBC_2.3.2 i'll test with gcc 3.4 next
<Merlin> i'm not sure testing for the guard function is enough <Merlin> i think you need to look for stack_smash at least alrighty, here it is: ayanami / # readelf -s /lib/libc.so.6 | grep smash 309: 000000000001db50 678 FUNC GLOBAL DEFAULT 11 __stack_smash_handler@@GLIBC_2.3.2
Ok, I'm frustrated as to how to actually check that /dev/erandom is being used. Here's a couple ideas. First of all, I was checking during development by doing an ebuild install and looking in: /var/tmp/portage/glibc-###/work/glibc-###/buildhere/csu I would then do: nm ssp.o | grep sysctl This should demonstrate that the frandom code is being used. Alternatively, you could look in your kernel log file for: May 11 21:15:48 dms1 kernel: frandom: Seeded global generator now (used by erandom) This should appear towards the end of the kernel boot messages. I'm not sure how good of a test this is, though. Anyone have a better method?
it wont compile with gcc 3.4, but that's something i already expected. oh well: gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux-x86-64.so.2 -B/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/ -B/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/csu/ -B/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/ -Wl,--version-script=/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/libpthread.map -Wl,-soname=libpthread.so.0 -Wl,-z,combreloc -Wl,--enable-new-dtags,-z,nodelete -Wl,--enable-new-dtags,-z,initfirst -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/math -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/elf -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/dlfcn -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/nss -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/nis -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/rt -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/resolv -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/crypt -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads -Wl,-rpath-link=/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/math:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/elf:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/dlfcn:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/nss:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/nis:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/rt:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/resolv:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/crypt:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads -o /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/libpthread.so -T /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/shlib.lds /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/csu/abi-note.o -Wl,--whole-archive /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/libpthread_pic.a -Wl,--no-whole-archive /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/elf/interp.os /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/libc.so /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/libc_nonshared.a /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/elf/ld.so /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.text+0x0): In function `dummy': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:14: multiple definition of `dummy' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.o(.text+0x0):/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.S:33: first defined here /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.text+0x20): In function `_init': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:25: multiple definition of `_init' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.o(.text+0x20):/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.S:55: first defined here /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.init+0x10): In function `_fini': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:20: multiple definition of `_fini' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.o(.init+0x10):/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.S:39: first defined here /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.o(.init+0x15): In function `_fini': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.S:86: warning: undefined reference to `i_am_not_a_leaf' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.init+0x19): In function `_fini': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:65: warning: undefined reference to `i_am_not_a_leaf' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.init+0x1e):/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:66: warning: undefined reference to `i_am_not_a_leaf' collect2: ld returned 1 exit status make[2]: *** [/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/libpthread.so] Error 1 make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/linuxthreads' make[1]: *** [linuxthreads/others] Error 2 make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2' make: *** [all] Error 2 !!! ERROR: sys-libs/glibc-2.3.2-r10 failed. !!! Function src_compile, Line 506, Exitcode 2 !!! (no error message)
Ned has helped me rediscover the obvious haha... to QA this ebuild/patch properly, please build glibc with USE="frandom" since it is not enabled by deafult (because it does theoretically reduce security). Then simply strace a binary and look for: open("/dev/erandom", O_RDONLY) = 3 read(3, "\323\320}\271", 4) = 4 close(3) = 0 Hopefully, the bytes being read will be different for you (otherwise we have a larger problem :).
Ok good. And in a chroot you see the calls to sysctl() ?
No bug reports.. Seems to be working great. And you on your way to being able to help maintain this long term. thanks.. Closing bug as FIXED
