Re: New hardened build support (coming) in F16
Hello, I didn't want to continue this discussion until I have a working F16 setup. Recently something got fixed so that install now works...so... On Tuesday, August 09, 2011 10:39:26 AM Adam Jackson wrote: On Tue, 2011-08-09 at 08:47 -0400, Steve Grubb wrote: My main concern is that the macro will be misapplied and overall performance will take a hit. That's a valid concern, but any hardened build would have this problem. I'm happy to talk about how the performance impact can be mitigated, but it seems unfair to blame a convenience macro for being convenient. I have been trying to test this macro and I see that something does get pulled into the build: cc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -- param=ssp-buffer-size=4 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 snip But testing the resulting binaries doesn't show any effect. Was this macro and any dependencies pushed out? I have redhat-rpm-config-9.1.0-15.fc16.noarch installed. I was not attempting to enforce a policy here. I was attempting to make applying hardened build flags easy in the common case. The problem is that if the now flag leaks into shared objects, then all programs linking against it will be slowed down. If this were used on tcpdump, would full relro leak to the libpcap? I'm not sure why you raise this concern in this particular context, I'm sorry, I was not very clear in what I meant. I intended to ask if you used the macro, would the library also being built pick up the now flag and therefore become full relro itself. I hope to answer this for myself, but I don't seem to be seeing any effect from the macro right now. Thus we can conclude that full- or partial-relro-ness is a per-object property, and that fully hardening an entire runtime-linked image requires hardening all of its components. This isn't entirely surprising, but it's nice to not be surprised. (Yes, Dmitri, it's good to be fine.) Agreed. The question then becomes which libraries you want to so harden. Again, this is a judgement call and I was not intending to imply that this would be applied globally; if I had, it wouldn't have been a macro at all. (Of course it's a friendly call.) For the case of tcpdump we could probably reasonably say all of its deps should be hardened: % LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc tcpdump -h | grep reloc 14319: relocation processing: /lib64/libz.so.1 (lazy) 14319: relocation processing: /lib64/libdl.so.2 (lazy) 14319: relocation processing: /lib64/libc.so.6 14319: relocation processing: /usr/lib64/libpcap.so.1 (lazy) 14319: relocation processing: /lib64/libcrypto.so.10 (lazy) 14319: relocation processing: tcpdump (lazy) 14319: relocation processing: /lib64/ld-linux-x86-64.so.2 What we are intending at the moment is partial relro for libraries unless the PLT is small. There had been a suggestion to make a tool that would examine it and if it were small enough suggest that it be made full relro. It was never determined how small is small enough. It would be a good area for someone to research. zlib is historically a CVE fest, pcap handles untrusted data by design, libcrypto is almost definitely worth hardening. For the case of libdl I suspect the glibc maintainers may have a functional reason to want it to not be -z now, but I've not investigated in that level of detail. Performance. They hardened everything they felt they could. We do need to work on how big the PLT can be before performance is impacted. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autodetecting insufficiently hardened builds (was: New hardened build support (coming) in F16)
Matthew Garrett wrote: Unless the checking is part of autoqa this simply isn't sufficient. There's a huge benefit to implementing it in the way that's easiest for maintainers. The earlier a problem is detected, the cheaper it is to fix. If I have understood AutoQA right, it gets involved only after I submit a package to updates-testing. Currently we (the AutoQA) are able to run the test either after you submit it to Bodhi, or even right after the build is finished in Koji (which is probably better for your use case). Feel free to discuss details with us in autoqa-devel [1]. [1] https://fedorahosted.org/mailman/listinfo/autoqa-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tue, Aug 09, 2011 at 02:20:53PM +0100, Matthew Garrett wrote: 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. Give Steve a break here. This is hardly the first time that things have been discussed at FESCO without even a courtesy email being sent to the people involved. In fact, back in 2008 I kicked up enough of a fuss about this that it's now a policy for Feature owners to be sent email about all meetings where their features are discussed: http://fedoraproject.org/wiki/Extras/SteeringComittee/Meeting-20081112 This clearly needs to be extended to changes in policy. Flagging a ticket as meeting is an obscure bit of wonkishness. A courtesy email should be sent before the meeting instead. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Wed, Aug 10, 2011 at 02:46:17PM +0100, Richard W.M. Jones wrote: This clearly needs to be extended to changes in policy. Flagging a ticket as meeting is an obscure bit of wonkishness. A courtesy email should be sent before the meeting instead. It's helpful to mail feature owners directly because the trac ticket will typically be in the name of the feature wrangler rather than the feature owner. https://fedorahosted.org/fesco/ticket/563 shows active discussion of the fact that we've been talking about this, links to the draft policy documents and makes it clear that this is being discussed in fesco meetings, and Steve's Cc:ed on all of that. It's been on the posted agendas for months. Yet the last time he was in #fedora-meeting appears to have been in February. That's not an impressive amount of involvement in the Fedora process. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Mon, 2011-08-08 at 23:16 -0400, Steve Grubb wrote: 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? most of the discussion happened via the weekly FESCo meetings, I believe, which are logged by meetbot - check http://meetbot.fedoraproject.org/fedora-meeting/ for the dates / times of fesco meetings. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On 08/08/2011 06:23 PM, Adam Jackson wrote: Once that's done (and redhat-rpm-config-9.1.0-15.fc16 has been gone through updates), if you're using a %configure-style spec file, defining the magic macro is all you have to do. The rpm macros will notice the macro, and put the right magic into CFLAGS and LDFLAGS, and everything is great and wonderful. I am not sure I understand the implications. If I compile my package which provides a daemon (=worth full relro) and few libraries with the magic macro, which defines LDFLAGS=-Wl,-z,now, all shared libraries from the build will get full relro too. What happens to applications, which link my libs? 1) will they start slower because of the relocations in the shared lib? 2) can they use prelink? Or should I hack Makefiles to use full relro only for daemons (and other security relevant binaries) and leave shared libs with partial relro only? Will be the daemon 'safe enough' if it consumes libraries with partial relro? -- Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
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. 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? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
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. 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. 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. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
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. 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. 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. The macro can't, but the maintainer can. The maintainer is presumably capable of, and responsible for, assessing whether her package would be a good candidate for this, and if so, testing builds done with the macro. Then if, performance is fine, on it goes. If performance sucks, it doesn't. -J 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. -Steve -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On 08/09/2011 08:47 AM, Steve Grubb wrote: 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. I think invoking coreutils is a pretty bogus example since it's full of relatively small binaries which don't take long to relocate. That being said, you don't *have* to use the macro. If your package needs a more nuanced approach to PIE and relro, and needs choices to be made on a per-binary basis, that's fine. There are a couple of approaches you could use here, most obviously just writing your makefile to be aware of these requirements. You own your packages and their makefiles. Knock yourself out. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
Steve Grubb wrote:
This is not the policy that I asked for.
Well, what Ajax described isn't a policy at all. It's a set of RPM macros
designed to make it easier to follow the (soon to be) policy. RPM macros can't
enforce the policy. Enforcement must be done elsewhere.
When you make a PIE executable,
you get ASLR which is good. But the way it does that is making a weakness
in the executable for the relocations. It causes a new segment to be
writable. So, you need full relro support when you do PIE to cover that
new weakness.
As far as I can see that is what the new RPM macros do, provided that the
configuration script supports both CFLAGS/CXXFLAGS/FFLAGS and LDFLAGS, or that
the spec file inserts %{optflags} and %{__global_ldflags} in the right places.
If
you think the macros do something wrong, it might help if you point out where
the error is.
What we want is this:
1) Everything is compiled with partial relro. Libraries, executables,
daemons, setuid/setgid/setcap apps.
Everything will be, if LDFLAGS or __global_ldflags is used correctly. The
current policy already requires that the applicable compiler flags set in the
system rpm configuration be honored. If we want to be pedantic we should
perhaps change that to compiler and linker flags.
2) Anything that is setgid/setuid/setcap/daemon also include the now
flags and is PIE.
https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags
mentions daemons, suid and capabilities, so you want to add setgid to that,
correct?
Do you also mean that you want should consider enabling changed to must
enable?
3) Anything that is parsing data from untrusted sources should also have
full relro/pie. That would be things like tcpdump/wireshark/firefox/evince
/file/netpbm etc.
I believe that's what the FESCo list side on
https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags
attempts to address. The etc is the hard part of course.
4) Anything that has pie, should should also have full relro, therefore we
need to double check anything with PIE to make sure its really a good idea.
Detecting programs that have been built with PIE but without -z now is
obviously beyond the scope of the _hardened_build macro, but your rpm-chksec
sounds like a good tool.
I sent an email to the fedora-test list last week announcing a program that
can check any package or the whole distribution for compliance with this
policy with the exception of rule #3 above. No idea how to make a heuristic
for that. The program is located here:
http://people.redhat.com/sgrubb/files/rpm-chksec
Perhaps that could be invoked automatically each time a package is built,
similarly to how /usr/lib/rpm/check-rpaths is used?
Björn Persson
signature.asc
Description: This is a digitally signed message part.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tue, Aug 09, 2011 at 10:17:29AM -0400, Steve Grubb wrote: On Tuesday, August 09, 2011 09:20:53 AM Matthew Garrett wrote: 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. Which means I'm very unclear on what you're unhappy about. The implementation Adam provided is what we agreed on in 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. 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. We have a huge number of packages that aren't built with autotools. 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. And that's why we're not enabling it across the board. The impact it has on any given package will depend on the size of the binaries and the way they're called. If imposing it upon coreutils results in a real increase in execution time then coreutils should adopt a different approach to implementing this, but if there are no benchmarks showing that it's a problem then it's really not worth caring about. 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). Which is fine, and then someone does a build just before release and screws it up. Unless the checking is part of autoqa this simply isn't sufficient. There's a huge benefit to implementing it in the way that's easiest for maintainers. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On 08/09/2011 10:17 AM, Steve Grubb wrote: I didn't fail to turn up to any of the meetings. ... 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. So you just failed to *participate* in the meetings then? This is an approach that should have been brought up in those discussions, not in a mailing list rant after the fact. 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. We did heed their advice, which you'd know if you'd either a) read what ajax has said here, or b) actually participated in the meetings where we discussed this. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tue, 2011-08-09 at 08:47 -0400, Steve Grubb wrote: My main concern is that the macro will be misapplied and overall performance will take a hit. That's a valid concern, but any hardened build would have this problem. I'm happy to talk about how the performance impact can be mitigated, but it seems unfair to blame a convenience macro for being convenient. 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. Sure, but you can't possibly know suid-ness until %files time anyway. I was not attempting to enforce a policy here. I was attempting to make applying hardened build flags easy in the common case. This isn't an excuse for not using one's brain as a packager. I had hoped I had made that clear, and I did not intend to imply that this was the _only_ way to get a hardened build, but I apologize for being insufficiently precise. 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. Yes, they would. coreutils might not be a suitable target for this flag. That's okay, coreutils is welcome to customize its build using something other than this convenience macro. If this were used on tcpdump, would full relro leak to the libpcap? I'm not sure why you raise this concern in this particular context, since the semantics would be the same regardless of this macro. But since this detail is worth expanding on, let's ask the dynamic linker what happens. Prelink makes this harder than you might hope, but if I'm reading the scrolls right, LD_USE_LOAD_BIAS=0 effectively turns it off, and LD_DEBUG=reloc will show us the steps in relocation processing. So what does a normal execution look like? % LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc /bin/ls /dev/null | grep reloc 6762: relocation processing: /lib64/libattr.so.1 (lazy) 6762: relocation processing: /lib64/libpthread.so.0 (lazy) 6762: relocation processing: /lib64/libdl.so.2 (lazy) 6762: relocation processing: /lib64/libc.so.6 6762: relocation processing: /lib64/libacl.so.1 (lazy) 6762: relocation processing: /lib64/libcap.so.2 (lazy) 6762: relocation processing: /lib64/librt.so.1 (lazy) 6762: relocation processing: /lib64/libselinux.so.1 (lazy) 6762: relocation processing: /bin/ls (lazy) 6762: relocation processing: /lib64/ld-linux-x86-64.so.2 Note that libc and ld.so are not described as lazy. This is because they have been linked with -z now: % eu-readelf -a /lib64/libc.so.6 | grep BIND_NOW FLAGS BIND_NOW STATIC_TLS % eu-readelf -a /lib64/ld-linux-x86-64.so.2 | grep BIND_NOW BIND_NOW What if we were to force the issue? % LD_BIND_NOW=1 LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc /bin/ls /dev/null | grep reloc 6766: relocation processing: /lib64/libattr.so.1 6766: relocation processing: /lib64/libpthread.so.0 6766: relocation processing: /lib64/libdl.so.2 6766: relocation processing: /lib64/libc.so.6 6766: relocation processing: /lib64/libacl.so.1 6766: relocation processing: /lib64/libcap.so.2 6766: relocation processing: /lib64/librt.so.1 6766: relocation processing: /lib64/libselinux.so.1 6766: relocation processing: /bin/ls 6766: relocation processing: /lib64/ld-linux-x86-64.so.2 Cool, looks like that does what we would expect. But does the environment variable have a different effect than if the executable itself were marked DT_BIND_NOW? Well, let's try with a program that _is_ already -z now: % eu-readelf -a /usr/bin/ssh | grep BIND_NOW BIND_NOW % LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc /usr/bin/ssh -V | grep reloc 6790: relocation processing: /lib64/libpthread.so.0 (lazy) 6790: relocation processing: /lib64/libkeyutils.so.1 (lazy) 6790: relocation processing: /lib64/libkrb5support.so.0 (lazy) 6790: relocation processing: /lib64/libfreebl3.so (lazy) 6790: relocation processing: /usr/lib64/libsasl2.so.2 (lazy) 6790: relocation processing: /lib64/libnspr4.so (lazy) 6790: relocation processing: /lib64/libplc4.so (lazy) 6790: relocation processing: /lib64/libplds4.so (lazy) 6790: relocation processing: /usr/lib64/libnssutil3.so (lazy) 6790: relocation processing: /usr/lib64/libnss3.so (lazy) 6790: relocation processing: /usr/lib64/libsmime3.so (lazy) 6790: relocation processing: /usr/lib64/libssl3.so (lazy) 6790: relocation processing: /lib64/libc.so.6 6790: relocation processing: /lib64/libcom_err.so.2 (lazy) 6790: relocation processing: /lib64/libk5crypto.so.3 (lazy) 6790:
Autodetecting insufficiently hardened builds (was: New hardened build support (coming) in F16)
Matthew Garrett wrote: Unless the checking is part of autoqa this simply isn't sufficient. There's a huge benefit to implementing it in the way that's easiest for maintainers. The earlier a problem is detected, the cheaper it is to fix. If I have understood AutoQA right, it gets involved only after I submit a package to updates-testing. Even better, when possible, is to detect problems during the build, so that I notice them when I test-build locally and can fix them before I even commit the changes to Git. Some checks are already done at build time, and Steve's points 1, 2 and 4 look like they should be possible to detect at build time too. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autodetecting insufficiently hardened builds (was: New hardened build support (coming) in F16)
On Tue, Aug 09, 2011 at 04:53:16PM +0200, Björn Persson wrote: Matthew Garrett wrote: Unless the checking is part of autoqa this simply isn't sufficient. There's a huge benefit to implementing it in the way that's easiest for maintainers. The earlier a problem is detected, the cheaper it is to fix. If I have understood AutoQA right, it gets involved only after I submit a package to updates-testing. Even better, when possible, is to detect problems during the build, so that I notice them when I test-build locally and can fix them before I even commit the changes to Git. Some checks are already done at build time, and Steve's points 1, 2 and 4 look like they should be possible to detect at build time too. Checking at build time is a developer aid, but doesn't prevent mistakes from slipping into the distribution. Having both would certainly be helpful. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New hardened build support (coming) in F16
tl;dr version: If you have a security-sensitive package, and wish to
enable some gcc-level hardening features with a modest performance
impact, you will soon be able to enable them (nearly) automagically by
rebuilding with this line in your spec file:
%define _hardened_build 1
Now for the details.
* 1: what are we trying to do?
There are three somewhat-overlapping build features in play here. The
first one is called relro, which instructs the linker to emit some
relocations in a special segment that can be marked read-only after
relocation processing is finished but before you call into main(). Or
in English: more things that you've asked to be const, will actually be
const. This on its own is quite cheap, and so it has been enabled
globally as of redhat-rpm-config-9.1.0-13.fc16.
By default, not all symbols are resolved that early in program
execution. In particular, functions are resolved lazily the first time
they're called. This makes startup faster, and since not all functions
are actually called in typical program execution, usually makes total
execution time faster. However, if all symbols were resolved early, the
relro feature could do a better job, and virtually all relocations could
be made read-only. The '-z now' flag to the linker makes this happen,
and an app so linked is said to be Full RELRO instead of Partial RELRO.
Finally, applications may be built as position-independent executables,
by passing -fPIC or -fPIE at build time and -pie at link time. This
allows the runtime linker to randomize the placement of the executable
at runtime, which makes it more difficult for an attacker to guess the
address of writeable memory.
* 2: how do we go about doing it?
The non-PIE parts of this are trivial, just pass the appropriate flags
to the linker and you're done. PIE is more difficult, both at build
time and at link time. Although both -fPIC and -fPIE produce
position-independent code at the assembly level, -fPIE will (at least on
amd64) produce relocation types that are only valid in an executable.
This means you can't just say -fPIE in CFLAGS: your libraries will fail
to link. (PIC objects in a PIE executable are fine; PIE objects in a
PIC library are not. When in doubt, -fPIC.)
Likewise, at link time, the -pie and -shared options are mutually
exclusive. ld.gold will simply refuse to execute if you specify both.
ld.bfd will (afaict) let whichever one comes last win, and if that
happens to be -pie when you're building a shared library it will fail to
link because it won't be able to find a _start symbol.
All of this is only an issue because most build systems don't let you
say different CFLAGS or LDFLAGS for shared libraries and executables. Sigh.
So instead, we'll teach gcc to figure it out. To do this we'll use the
-specs flag to pass some rewrite rules to the compiler driver. At
compile time, if we don't see -fPIC or -fPIE on the command line, we'll
add -fPIC. At link time, if we don't see -shared, we'll add -pie. This
way we build relocatable objects that are always suitable for either
type of final link object, and we'll only attempt to build a PIE if we
know we're not building a shared library. Victory!
* 3: what does this mean for you?
The link-time bit of the last paragraph required a bit of gcc magic to
get right (previously specs rules could only add strings to the command
line of the program to invoke; they could not rewrite gcc's notion of
which flags had been passed in the first place). Thanks to a patch from
Jakub Jelinek, this is now fixed in gcc-4.6.1-7.fc16, and will be in gcc
4.7 and later. As a result, %defined _hardened_build 1 will not work
until that gcc update has gone through.
Once that's done (and redhat-rpm-config-9.1.0-15.fc16 has been gone
through updates), if you're using a %configure-style spec file, defining
the magic macro is all you have to do. The rpm macros will notice the
macro, and put the right magic into CFLAGS and LDFLAGS, and everything
is great and wonderful.
If you're _not_ using %configure, then you have to do whatever is
conventional for your build system to get CFLAGS and LDFLAGS inherited
properly. For CFLAGS, this will be $RPM_OPT_FLAGS or %{optflags} as
before. As of rpm-4.9.1-3.fc16, you will be able to say $RPM_LD_FLAGS
for the corresponding LDFLAGS values. Until then, there is no such
shell variable, but you can get the same effect from
%{?__global_ldflags}. Yes, that's ugly, sorry.
If you are the owner of one of the packages listed here:
https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags
Then I have locally built (though not extensively tested) your package
with the appropriate specfile modifications, and the results do indeed
appear to be fully hardened. If you would like to handle the rebuilds
yourself, please let me know. Otherwise I will submit them myself once
the relevant updates have gone through.
If you've
Re: New hardened build support (coming) in F16
Hi, On Mon, Aug 08, 2011 at 12:23:43PM -0400, Adam Jackson wrote: %define _hardened_build 1 just wondering: Is %define really correct here or does it need to be %global? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On 8/8/11 3:52 PM, Till Maas wrote: On Mon, Aug 08, 2011 at 12:23:43PM -0400, Adam Jackson wrote: %define _hardened_build 1 just wondering: Is %define really correct here or does it need to be %global? I've been using %define out of habit, but either one works. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Mon, 2011-08-08 at 12:23 -0400, Adam Jackson wrote: If you've made it to the end, congratulations. Please let me know if there are any issues, or any questions I can answer. In particular if the performance impact of these flags is excessive for you, there are some ways it can be mitigated that are out of scope for this particular email. awesome stuff, thanks FESCo for following through so thoroughly on this one! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
* 3: what does this mean for you? ... and your users, and your software maintenance budget: If you enable it, then the apps in your package: 1) Cannot be prelink-ed. This likely costs time and space (RAM, swap) at run time. The magnitude of the cost can vary from almost nothing to several seconds and hundreds of pages per invocation. An app which uses a large number of shared libraries might incur the highest costs, because if an app is not prelinked itself then the runtime linker ld-linux must ignore any prelinking of the shared libraries that the app uses. 2) Might produce different results, especially if any of LD_PRELOAD, dlopen, dlsym(RTLD_NEXT,), or ltrace is involved. [Most of this is due to using -z now.] 3) Might reveal formerly-hidden bugs which depend on numerical values or accidental relationships of addresses at run time. 4) Might be harder to debug when the bug is intermittent or is observed only in an end-user environment. Most apps ought to be good enough [by now] so that 2), 3), and 4) do not matter. But 1) might be important. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Monday, August 08, 2011 12:23:43 PM Adam Jackson wrote:
* 2: how do we go about doing it?
All of this is only an issue because most build systems don't let you
say different CFLAGS or LDFLAGS for shared libraries and executables.
Sigh.
So instead, we'll teach gcc to figure it out. To do this we'll use the
-specs flag to pass some rewrite rules to the compiler driver. At
compile time, if we don't see -fPIC or -fPIE on the command line, we'll
add -fPIC. At link time, if we don't see -shared, we'll add -pie. This
way we build relocatable objects that are always suitable for either
type of final link object, and we'll only attempt to build a PIE if we
know we're not building a shared library. Victory!
This is not the policy that I asked for. When you make a PIE executable, you
get ASLR which is good. But the way it does that is making a weakness in the
executable for the relocations. It causes a new segment to be writable. So,
you need full relro support when you do PIE to cover that new weakness. But
full relro can be expensive, so we only want that if the PLT is small.
(Defining small is still TBD.)
What we want is this:
1) Everything is compiled with partial relro. Libraries, executables, daemons,
setuid/setgid/setcap apps.
2) Anything that is setgid/setuid/setcap/daemon also include the now flags
and is PIE.
3) Anything that is parsing data from untrusted sources should also have full
relro/pie. That would be things like tcpdump/wireshark/firefox/evince
/file/netpbm etc.
4) Anything that has pie, should should also have full relro, therefore we
need to double check anything with PIE to make sure its really a good idea.
I sent an email to the fedora-test list last week announcing a program that
can check any package or the whole distribution for compliance with this
policy with the exception of rule #3 above. No idea how to make a heuristic
for that. The program is located here:
http://people.redhat.com/sgrubb/files/rpm-chksec
* 3: what does this mean for you?
The link-time bit of the last paragraph required a bit of gcc magic to
get right (previously specs rules could only add strings to the command
line of the program to invoke; they could not rewrite gcc's notion of
which flags had been passed in the first place). Thanks to a patch from
Jakub Jelinek, this is now fixed in gcc-4.6.1-7.fc16, and will be in gcc
4.7 and later. As a result, %defined _hardened_build 1 will not work
until that gcc update has gone through.
Once that's done (and redhat-rpm-config-9.1.0-15.fc16 has been gone
through updates), if you're using a %configure-style spec file, defining
the magic macro is all you have to do. The rpm macros will notice the
macro, and put the right magic into CFLAGS and LDFLAGS, and everything
is great and wonderful.
Except that is not exactly the policy I asked for. :)
If you're _not_ using %configure, then you have to do whatever is
conventional for your build system to get CFLAGS and LDFLAGS inherited
properly. For CFLAGS, this will be $RPM_OPT_FLAGS or %{optflags} as
before. As of rpm-4.9.1-3.fc16, you will be able to say $RPM_LD_FLAGS
for the corresponding LDFLAGS values. Until then, there is no such
shell variable, but you can get the same effect from
%{?__global_ldflags}. Yes, that's ugly, sorry.
If you are the owner of one of the packages listed here:
https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_fl
ags
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.
Then I have locally built (though not extensively tested) your package
with the appropriate specfile modifications, and the results do indeed
appear to be fully hardened. If you would like to handle the rebuilds
yourself, please let me know. Otherwise I will submit them myself once
the relevant updates have gone through.
I anyone does this and the program is used extensively, we need to know the
extent of the performance hit. If this flag automatically turns on full relro
for libraries, we have a problem.
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?
Thanks,
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
