[uClibc] Re: hardening uclibc

Peter S. Mazinger ps.m at gmx.net
Sat Oct 30 13:22:24 UTC 2004


On Sat, 30 Oct 2004, Peter S. Mazinger wrote:

> Hello
> 
> I have thought of following enhancements:
> 
> we change UCLIBC_PROPOLICE to UCLIBC_HAS_SSP (or HAS_PROPOLICE), this will 
> only add ssp.c, but should also check for libgcc_s not having __guard, 
> else we end up w/ double __guard.
> 
> remove UCLIBC_PIE_SUPPORT (and build Scrt1.o on all archs if present)
> 
> remove crt0.o, "this was only needed by the wrapper" citing Erik, so  
> "replacing" crt0.o w/ Scrt1.o does not add more files to the sources

ok, leave crt0.o untouched, if some are using it, then we add only a 904 
byte file to the development stuff (curently only for x86 and ppc)

> we add a config option
> UCLIBC_SECURE_BUILD as generic security enhancement (only build related)
> and some options depending on the above
> 
> UCLIBC_BUILD_SSP build w/ -fstack-protector[-all] everything that is 
> possible (depends on UCLIBC_HAS_SSP too) and has to do the __guard check 
> too in libgcc_s not ending up w/ 2 __guard symbols.

I have to ask again ;-(
Does anyone have an idea how a script can be run before a Config.in option 
is activated for ex. having an .config file and running make oldconfig.

It would be more secure, to check for proper gcc that supports 
-fstack-protector and was built so, that libgcc_s does not include __guard 
symbol. If both conditions are not met, the UCLIBC_HAS_SSP shouldn't even 
show up as an option.
I can't find a way for this, unless I patch scripts/*, but I do not like 
that approach.

> UCLIBC_BUILD_PIE build ldd/iconv/readelf as PIE
this could also need a test like the above, because only gcc-3.4 has pie 
support in the pristine sources, gcc-3.3.x has to be patched for it, 
gcc-2.9x does not even have patches for it. binutils could also be checked 
to look for ld --help | grep pie

> 
> UCLIBC_BUILD_RELRO build everything w/ -z relro
the same applies here to, we could check for
ld --help | grep relro

another way would be to introduce attribute_relro
glibc uses attribute_relro (like attribute_hidden) and does explicit
marking, not leaving everything to be done by ld.

So, generally a way to check for support in the toolchain before we show 
an option would be better, else we allow the user to enable some option, 
but have to disable it later in Rules.mak/Makefile, because it will cause 
problems. The user remains w/ a false sense of security.

Peter

> 
> UCLIBC_BUILD_NOW build everything w/ -z now
> we could also add some optimization (add -O1 to ld) to compensate for 
> -z now "slowness"
> 
> Comments?
> 
> Peter
> 
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list