New hardened build support (coming) in F16

[Steve Grubb]

On Tuesday, August 09, 2011 09:20:53 AM Matthew Garrett wrote:
> > Taking RHEL6 through common criteria and FIPS-140, filing dozens of
> > security  bugs after studying some problems and sending patches. I am
> > monitoring the FESCO ticket, but I don't monitor fedora-devel all the
> > time because there are way too many arguments for my taste. Regardless,
> > should there not have been some hint about anything on the ticket? I
> > responded to any review request for the wiki page and such.
> 
> 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.


> 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.


> > My main concern is that the macro will be misapplied and overall
> > performance  will take a hit. I don't know how a macro can tell the
> > intent of an application as it links it. There has not been a chmod so
> > that it knows this is setuid and needs more protection. For example, if
> > coreutils was built with this (and coreutils seems to be correct as is)
> > because it has setuid programs, then would all apps get the PIE/Full
> > RELRO treatment? If so, many of coreutils apps are called constantly by
> > shell scripts. If this were used on tcpdump, would full relro leak to
> > the libpcap? I suppose I could test this as soon as I set up a rawhide
> > vm...but this is what concerns me about the approach.
> 
> 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.


> 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).

I also have a bunch of other test scripts here:
http://people.redhat.com/sgrubb/security
if you want to check the distro more.


> Like anything, it's a tradeoff. If it causes problems then we can tweak 
> the implementation, and if you'd prefer you can think of this as a 
> starting point. Nothing FESCO comes up with is set in stone. We'll be 
> happy to modify the policy in response to technical feedback.

OK.

Thanks,
-Steve