Expanding the list of "Hardened Packages"

[Steve Grubb]

On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote:
> On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote:
> > > On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > > > On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote:
> > > > > "_hardened_build" rpm spec macro can be used to harden a package.
> > > > > 
> > > > > For an example, see
> > > > > http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec
> > > > 
> > > > This flag is overly aggressive. We have a list of programs that need
> > 
> > PIE
> > 
> > > > enabled and doing more isn't necessarily constructive.
> > > 
> > > Why exactly it "isn't necessarily constructive"?  If you have hard data,
> > > please share :)
> > 
> > Because PIE is only supposed to be on long running apps and setuid apps.
> > If
> > its on everything, it will slow the system down too much and then you have
> > the
> > knee jerk reaction to remove it from anything. We want it applied when
> > needed
> > and otherwise not.
> 
> How much does it slow things down? I'm fairly certain you don't have any
> good data on this point. Dhiru is working out how to best figure out FWIW.
> 
> I'm willing to agree that PIE on x86 is going to be very slow due to
> register pressure. However, we should consider revisiting what we want
> built as PIE. Is Firefox a long running process?

Firefox fits into the category of a parser of untrusted media. Therefore it 
should hardened.


> It is on my system. Revisiting our current list and trying to understand our
> needs is never a bad thing to do. Existing architectures are different now
> than they were when that list was created, no harm comes from talking about
> it.

I think the list, if enforced, is good enough for our needs. PIE is only part 
of the issues. Other things that are more important in my opinion.

1) Heap randomization is only 14 bits! If PIE is enabled, it has 29 bits of 
randomization. We need to do something about that.
2) Even though we have only a handful of apps violating NX stack, we have a 
bunch of apps that mmap writable and executabel memory. For example, polkitd 
running as root has WX memory. Mosty of KDE does, so does Cinnamon. Part of 
the problem seems to be libjs. What its doing is partially compiling, 
compiling as needed, optimizes as the script runs. If you look into libjs, you 
see that it has calls to mprotect to actually solve the problem. However, 
there is an obvious typo that disables it. So, when you fix that, you find out 
the actual use of the protections is completely missing. The code is BSD...so 
maybe the actual use is behind closed doors.
3) We need the -fstack-protector-string patch for gcc. This effectively doubles 
the coverage of the stack protector. For example, CVE-2013-0288 would have 
been stopped -fstack-protector-strong.
4) We need to get fortify_source macros into gnulib.

Last week I was looking at nspr and wondering why fortify_source was not 
getting used and found that it wrapped functions for "portability". For 
example, it has PL_strcpy which only wraps strcpy. The problem is the size 
information is lost by the wrapping so that the fortify macros have nothing to 
work with. I know this is a common technique, I've seen it a lot. But this 
idiom defeats a security mechanism.

PIE is a second layer defence. Assuming an attacker has exploited something, 
it makes ROP harder to do. I'd like to fix some of these other issues that stop 
attacks at the beginning.

-Steve