Dear Gentoo developers, when Dr. Etoh has finished working on the new updated propolice patches, influenced by our extensive testing, which will then make it into the -r4 versions of current glibc and gcc, i would like the responsible rollout teams to create new livecd's and new stages 1-3 to get the final steps of the gcc/glibc propolice migration done in the first quarter of 2004.
This includes normal environments as well as the hardened livecd and/or stages for etdyn-ssp and selinux support. All supported hardware platforms, except hppa where propolice cannot be utilized due to an upgrowing stack, are affected by the last steps of the propolice migration on Gentoo Linux. At the moment, most if not all livecd and the stages found in the field and on the mirrors contain a glibc without the guard symbols and a gcc with the guard symbols in place. When a user installs a fresh system, she or he has to obey certain baby steps to create a working condition for using propolice either in make.conf:CFLAGS or with the available hardened-gcc packages. It is also important for ensuring gcc -static not failing with an error message describing multiple occurrences of symbols, this error message with running "gcc -static" may even happen without using the propolice -fstack-protector in CFLAGS or having hardened-gcc on a system, it is produced by the linker detecting multiple copies of the propolice object and functions in glibc and libgcc during the final -static linking run when the glibc has been compiled with the guard patch and the gcc in place has not yet been compiled with the move-propolice-to-glibc patch. recommended procedure for stage3: = emerge sync (get the current portage tree from the internet) - emerge glibc gcc (this will emerge glibc-2.3.2-r3 and gcc-3.2.3-r3) - emerge =uv system recommended procedure for stage2: = emerge sync (get the current portage tree from the internet) - emerge glibc gcc (this will emerge glibc-2.3.2-r3 and gcc-3.2.3-r3) - emerge system The updated glibc emerge will add the guard object and the necessary functions from propolice to the glibc and the following gcc emerge will remove the guard object and the corresponding functions. Also because of the migration, users of stage1 can experience bootstrap.sh problems due to the fact that the glibc may get emerged after the gcc which will then lead to the situation that gcc has not removed the propolice guard object and the setup functions due to a glibc not found on the system that has the guard object. When we can make sure that stage1 bootstrap.sh does the emerge of the glibc before gcc gets emerged during bootstrapping, we are safe. Otherwise subsequent emerges of ebuilds could fail with -static error messages or in the case of hardened with -fstack-protector failing on ebuilds. Thanks for your attention and patience with the hardened team. So far, the scanner script utilized in the gcc ebuild is generating only true positives and is urging users to reinstall the components depending on the __guard object in the libgcc before the gcc can be emerged. This will prevent systems from getting inconsistent due to binaries like python2.2 relying on the libgcc __guard object. Please do not remove or tamper with this safety belt in the ebuild. You can contact me and get information from the comments in the bug 25299 about the procedures necessary for the migration. The author of PaX is preparing a propolice supported, text relocation free, etdyn-based XFree86 server with a dynamic library module loading mechanism instead of the old ELF-based method. Also, the emerging of openoffice with hardened-gcc -yet_exec using propolice is not yet failing here with gcc ICE after some hours compiling time, if this finally succeeds, gcc-3.3.2-r3 will be the first known good gcc to compile openoffice with the propolice stack-protector. I would like to give credit to the involved Gentoo developers and testers, the upstream and related security specialists in the vicinity of the Gentoo Hardened sub-projects for their ongoing commitment and leading solution support in the sector of host-based userland hardening - without the combined efforts and the widely available helping hands in the whole Gentoo developer community, these advancements would have never been possible. Alexander -- Alexander Gabert <[EMAIL PROTECTED]> http://www.gentoo.org/proj/en/hardened -- [EMAIL PROTECTED] mailing list
