On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote:
On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb <sgrubb(a)redhat.com>
> On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote:
> > On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb <sgrubb(a)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
> > > >
> > > > 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
> > > enabled and doing more isn't necessarily constructive.
> > Why exactly it "isn't necessarily constructive"? If you have
> > please share :)
> Because PIE is only supposed to be on long running apps and setuid apps.
> its on everything, it will slow the system down too much and then you have
> knee jerk reaction to remove it from anything. We want it applied when
> 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
It is on my system. Revisiting our current list and trying to
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
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.