On Wed, Aug 10, 2011 at 02:46:17PM +0100, Richard W.M. Jones wrote:

> This clearly needs to be extended to changes in policy. Flagging a
> ticket as "meeting" is an obscure bit of wonkishness. A courtesy
> email should be sent before the meeting instead.

It's helpful to mail feature owners directly because the trac ticket
will typically be in the name of the feature wrangler rather than the
feature owner. https://fedorahosted.org/fesco/ticket/563 shows active
discussion of the fact that we've been talking about this, links to the
draft policy documents and makes it clear that this is being discussed
in fesco meetings, and Steve's Cc:ed on all of that. It's been on the
posted agendas for months. Yet the last time he was in #fedora-meeting
appears to have been in February. That's not an impressive amount of
involvement in the Fedora process.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel