New hardened build support (coming) in F16

[Matthew Garrett]

On Tue, Aug 09, 2011 at 08:47:16AM -0400, Steve Grubb wrote:
> On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote:
> > On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote:
> > > 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.
> > 
> > Because it's SUID.
> 
> ?  Its one in the target group.

Yes. The list isn't intended to be exhaustive - it's already been made 
clear above that SUID applications should be covered.

> > > 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?
> > 
> > We spent weeks discussing this. Where were you during the meetings?
> 
> 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 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.

> 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?) increases the risk that someone will make a mistake 
and we'll ship code that's less secure than it was supposed to be.

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.

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