New hardened build support (coming) in F16

[Steve Grubb]

Hello,

I didn't want to continue this discussion until I have a working F16 setup. Recently 
something got fixed so that install now works...so...

On Tuesday, August 09, 2011 10:39:26 AM Adam Jackson wrote:
> On Tue, 2011-08-09 at 08:47 -0400, Steve Grubb wrote:
> > My main concern is that the macro will be misapplied and overall
> > performance will take a hit.
> 
> That's a valid concern, but any hardened build would have this problem.
> I'm happy to talk about how the performance impact can be mitigated, but
> it seems unfair to blame a convenience macro for being convenient.

I have been trying to test this macro and I see that something does get pulled into 
the build:

cc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --
param=ssp-buffer-size=4 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 <snip>

But testing the resulting binaries doesn't show any effect. Was this macro and any 
dependencies pushed out? I have redhat-rpm-config-9.1.0-15.fc16.noarch installed.


> I was not attempting to enforce a policy here.  I was attempting to make
> applying hardened build flags easy in the common case. 

The problem is that if the "now" flag leaks into shared objects, then all programs 
linking against it will be slowed down.


> > If this were used on tcpdump, would full relro leak to the libpcap?
> 
> I'm not sure why you raise this concern in this particular context,

I'm sorry, I was not very clear in what I meant. I intended to ask if you used the 
macro, would the library also being built pick up the "now" flag and therefore become 
full relro itself. I hope to answer this for myself, but I don't seem to be seeing any 
effect from the macro right now.


> Thus we can conclude that full- or partial-relro-ness is a per-object
> property, and that fully hardening an entire runtime-linked image
> requires hardening all of its components.  This isn't entirely
> surprising, but it's nice to not be surprised.  (Yes, Dmitri, it's good
> to be fine.)

Agreed.

> The question then becomes which libraries you want to so harden.  Again,
> this is a judgement call and I was not intending to imply that this
> would be applied globally; if I had, it wouldn't have been a macro at
> all.  (Of course it's a friendly call.)  For the case of tcpdump we
> could probably reasonably say all of its deps should be hardened:
> 
> % LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc tcpdump -h |& grep reloc
>      14319:	relocation processing: /lib64/libz.so.1 (lazy)
>      14319:	relocation processing: /lib64/libdl.so.2 (lazy)
>      14319:	relocation processing: /lib64/libc.so.6
>      14319:	relocation processing: /usr/lib64/libpcap.so.1 (lazy)
>      14319:	relocation processing: /lib64/libcrypto.so.10 (lazy)
>      14319:	relocation processing: tcpdump (lazy)
>      14319:	relocation processing: /lib64/ld-linux-x86-64.so.2

What we are intending at the moment is partial relro for libraries unless the PLT is 
small. There had been a suggestion to make a tool that would examine it and if it were 
small enough suggest that it be made full relro. It was never determined how small is 
small enough. It would be a good area for someone to research.


> zlib is historically a CVE fest, pcap handles untrusted data by design,
> libcrypto is almost definitely worth hardening.  For the case of libdl I
> suspect the glibc maintainers may have a functional reason to want it to
> not be -z now, but I've not investigated in that level of detail.

Performance. They hardened everything they felt they could. We do need to work on how 
big the PLT can be before performance is impacted.

-Steve