New hardened build support (coming) in F16

[Steve Grubb]

On Monday, August 08, 2011 12:23:43 PM Adam Jackson wrote:
> * 2: how do we go about doing it?
> All of this is only an issue because most build systems don't let you
> say different CFLAGS or LDFLAGS for shared libraries and executables. 
> Sigh.
> 
> So instead, we'll teach gcc to figure it out.  To do this we'll use the
> -specs flag to pass some rewrite rules to the compiler driver.  At
> compile time, if we don't see -fPIC or -fPIE on the command line, we'll
> add -fPIC.  At link time, if we don't see -shared, we'll add -pie.  This
> way we build relocatable objects that are always suitable for either
> type of final link object, and we'll only attempt to build a PIE if we
> know we're not building a shared library.  Victory!

This is not the policy that I asked for. When you make a PIE executable, you 
get ASLR which is good. But the way it does that is making a weakness in the 
executable for the relocations. It causes a new segment to be writable. So, 
you need full relro support when you do PIE to cover that new weakness. But 
full relro can be expensive, so we only want that if the PLT is small. 
(Defining small is still TBD.)

What we want is this:
1) Everything is compiled with partial relro. Libraries, executables, daemons, 
setuid/setgid/setcap apps.
2) Anything that is setgid/setuid/setcap/daemon also include the "now" flags 
and is PIE.
3) Anything that is parsing data from untrusted sources should also have full 
relro/pie. That would be things like tcpdump/wireshark/firefox/evince 
/file/netpbm etc.
 4) Anything that has pie, should should also have full relro, therefore we 
need to double check anything with PIE to make sure its really a good idea.

I sent an email to the fedora-test list last week announcing a program that 
can check any package or the whole distribution for compliance with this 
policy with the exception of rule #3 above. No idea how to make a heuristic 
for that. The program is located here:

http://people.redhat.com/sgrubb/files/rpm-chksec


> * 3: what does this mean for you?
> 
> The link-time bit of the last paragraph required a bit of gcc magic to
> get right (previously specs rules could only add strings to the command
> line of the program to invoke; they could not rewrite gcc's notion of
> which flags had been passed in the first place).  Thanks to a patch from
> Jakub Jelinek, this is now fixed in gcc-4.6.1-7.fc16, and will be in gcc
> 4.7 and later.  As a result, %defined _hardened_build 1 will not work
> until that gcc update has gone through.
> 
> Once that's done (and redhat-rpm-config-9.1.0-15.fc16 has been gone
> through updates), if you're using a %configure-style spec file, defining
> the magic macro is all you have to do.  The rpm macros will notice the
> macro, and put the right magic into CFLAGS and LDFLAGS, and everything
> is great and wonderful.

Except that is not exactly the policy I asked for. :)


> If you're _not_ using %configure, then you have to do whatever is
> conventional for your build system to get CFLAGS and LDFLAGS inherited
> properly.   For CFLAGS, this will be $RPM_OPT_FLAGS or %{optflags} as
> before.  As of rpm-4.9.1-3.fc16, you will be able to say $RPM_LD_FLAGS
> for the corresponding LDFLAGS values.  Until then, there is no such
> shell variable, but you can get the same effect from
> %{?__global_ldflags}.  Yes, that's ugly, sorry.
> 
> If you are the owner of one of the packages listed here:
> 
> https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_fl
> ags

This list is woefully incomplete. I would advocate a much larger list. For 
example, sudo is a very important program that we make security claims about. 
It is not on that list.


> Then I have locally built (though not extensively tested) your package
> with the appropriate specfile modifications, and the results do indeed
> appear to be fully hardened.  If you would like to handle the rebuilds
> yourself, please let me know.  Otherwise I will submit them myself once
> the relevant updates have gone through.

I anyone does this and the program is used extensively, we need to know the 
extent of the performance hit. If this flag automatically turns on full relro 
for libraries, we have a problem.

I think there should have been some discussion about this on the FESCO request 
I submitted. I have some concerns about what was implemented. Are there bz 
filed for this or more discussion about it somewhere?

Thanks,
-Steve