New hardened build support (coming) in F16

[Matthew Garrett]

On Tue, Aug 09, 2011 at 10:17:29AM -0400, Steve Grubb wrote:
> On Tuesday, August 09, 2011 09:20:53 AM Matthew Garrett wrote:
> > You can't bring a policy to FESCO, fail to turn up to any of the 
> > meetings
> 
> I didn't fail to turn up to any of the meetings. I watched the issue and 
> attended until it was approved. I then turned my attention to other things 
> like how to scan a distribution to find packages that need updating. I posted a 
> link to my script on the ticket. Just adding a global LDFLAGS accomplishes 
> most of what is needed. The only issue left is when you have a 
> daemon/setuid/setgid/setcap or something parsing untrusted media. Those are 
> all the kind of packages that the maintainer should be skilled enough that 
> they ought to know how to add flags since they would be attack vectors.

Which means I'm very unclear on what you're unhappy about. The 
implementation Adam provided is what we agreed on in the meetings.

> > and then be surprised if the enacted proposal doesn't perfectly 
> > match yours. The ticket was flagged "meeting" up until the point where 
> > it was closed which means it's under active consideration, and the 
> > meeting summaries posted to fedora-devel contained the various proposals 
> > and action items that we worked through.
> 
> I would rather have seen a macro added to auto tools to detect gcc support for 
> this so that upstream developers can more easily add the support natively for 
> all distributions.

We have a huge number of packages that aren't built with autotools.

> > The aim was to come up with a policy that is straightforward for 
> > maintainers to implement. Making it more complex for small performance 
> > benefits (coreutils applications may be called often, but they're also 
> > pretty tiny - have you actually measured a significant difference in 
> > real world cases?)
> 
> The compiler folks objected to enable full relro/pie across the board, so I 
> assume they know there is a penalty and we should heed their advice.

And that's why we're not enabling it across the board. The impact it has 
on any given package will depend on the size of the binaries and the way 
they're called. If imposing it upon coreutils results in a real increase 
in execution time then coreutils should adopt a different approach to 
implementing this, but if there are no benchmarks showing that it's a 
problem then it's really not worth caring about.

> > increases the risk that someone will make a mistake 
> > and we'll ship code that's less secure than it was supposed to be.
> 
> That is why I developed a lot of test scripts...so that we check the 
> distribution for security issues. All you need to do is get an install 
> everything setup, and run ./rpm-chksec --all  it will grade all the installed 
> packages to see if the comply (with the exception of the parses untrusted 
> media use case).

Which is fine, and then someone does a build just before release and 
screws it up. Unless the checking is part of autoqa this simply isn't 
sufficient. There's a huge benefit to implementing it in the way that's 
easiest for maintainers.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org