On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote: > On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb <sgrubb@xxxxxxxxxx> 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@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
