Building ports with stack-protector
in [Ports]
|
From: Janne Snabb on 29 May 2010 22:19 Hi, Big thanks to the folks who made "make buildworld" to use -fstack-protector by default since 8.0. This should make FreeBSD more secure. How about the ports system? I tried to re-build all my ports some time ago with the stack-protector enabled by adding -fstack-protector in CFLAGS in /etc/make.conf. Most ports build & work fine with this enabled, but there are several exceptions. Some libraries cannot be compiled with this (either the build fails or linking other programs which use the library later fail). Also some programs that do strange things fail to build or run. IMHO it would make sense to make some sort of framework in the ports system to support this. I think there should be a port Makefile knob which tells if the port can be built with the stack-protector or not. Now it is difficult to determine on port-by-port basis if it can be enabled or not. Is there any work or plans to accomplish this? It would be great to compile at least all the network facing server programs with this enabled. I have an impression that more than 90% of programs can be compiled with the stack-protector. For libraries the percentage might be less. What do you think? Best Regards, -- Janne Snabb / EPIPE Communications snabb(a)epipe.com - http://epipe.com/ _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Garrett Cooper on 29 May 2010 22:53 On Sat, May 29, 2010 at 7:19 PM, Janne Snabb <snabb(a)epipe.com> wrote: > Hi, > > Big thanks to the folks who made "make buildworld" to use > -fstack-protector by default since 8.0. This should make FreeBSD > more secure. > > How about the ports system? > > I tried to re-build all my ports some time ago with the stack-protector > enabled by adding -fstack-protector in CFLAGS in /etc/make.conf. > Most ports build & work fine with this enabled, but there are several > exceptions. Some libraries cannot be compiled with this (either the > build fails or linking other programs which use the library later > fail). Also some programs that do strange things fail to build or > run. > > IMHO it would make sense to make some sort of framework in the ports > system to support this. I think there should be a port Makefile > knob which tells if the port can be built with the stack-protector > or not. Now it is difficult to determine on port-by-port basis if > it can be enabled or not. > > Is there any work or plans to accomplish this? > > It would be great to compile at least all the network facing server > programs with this enabled. I have an impression that more than 90% > of programs can be compiled with the stack-protector. For libraries > the percentage might be less. > > What do you think? While this might be an interesting feature, I think that there must be a line drawn at what is and what isn't acceptable to maintain. Check and see whether or not a similar feature exists in other compilers. If so, then I'd start noting which ports are and which aren't usable with this feature, and maybe approach the portmgr folks to see what they think. Maintaining this feature would be a pain though because it would require a lot more QA work beyond just seeing whether or not things build. Cheers, -Garrett _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Janne Snabb on 30 May 2010 02:49 On Sat, 29 May 2010, Garrett Cooper wrote: > While this might be an interesting feature, I think that there must be > a line drawn at what is and what isn't acceptable to maintain. Certainly so. > Check and see whether or not a similar feature exists in other > compilers. Based on a quick web search for "clang stack-protector" clang seems to have this feature. > Maintaining this feature would be a pain though because it would > require a lot more QA work beyond just seeing whether or not things > build. I am not proposing that a switch from the current situation to having most ports build with stack-protector should be done overnight or quickly. This is simply not possible. It is very different from /usr/src. I am rather proposing that the port framework would have support for this feature so that individual port maintainers could enable it in their ports if they are confident that the port works fine with the stack-protector. This should be initially entirely optional, some time later it should be recommended for new/updated ports, and maybe after couple of years it could be made mandatory for ports to specify this. This would work as follows: 1. A port maintainer could specify USE_STACK_PROTECTOR=yes in their Makefile if they are confident that the port works with it. If they know that the port does not work with it, they could specify USE_STACK_PROTECTOR=no. If they do not know or care, they would not need to do anything. 2. An overly paranoid user could specify WITH_STACK_PROTECTOR=yes or WITH_STACK_PROTECTOR=no in /etc/make.conf according to their wishes (depending if they are paranoid about security or paranoid about port breakage). There should be a warning that WITH_STACK_PROTECTOR=yes is not supported and should be avoided by general users and that the knob should be left undefined before sending any problem reports. Based on these variables the port infrastructure would decide whether to add "-fstack-protector" to CFLAGS or not: Port Makefile USE_STACK_PROTECTOR yes undef no In /etc/make.conf: +-------------------- WITH_STACK_PROTECTOR yes | yes yes no undef | yes no no no | no no no I hope that the above table displays somewhat correctly. Anyway the point is that "no" should be stronger in the decision logic than "yes" to avoid sudden breakage of a huge amount of ports. The example variable names in this post come just quickly from the top of my head, so please do not flame me for that at this point. I am just trying to illustrate how this logic could be made, instead of proposing the exact way how this should be implemented. Obviously more thought should be put in this before it could be implemented. That is the reason for my original post: to start thinking and discussing about it. This way some port maintainers could decide to introduce USE_STACK_PROTECTOR in their ports when they have time or interest in the issue. The decision yes/no would impose a bit more QA work on the port maintainers, but as it would be entirely optional, it should not be a real burden to anyone. The required changes in the port infrastructure (files in /usr/ports/Mk) would be quite trivial. I think the long term security benefits would far outweigh the burden of implementing this in the port infrastructure. In the long run this should also reduce the amount of existing but previously undiscovered stack overflow bugs in software in general because the bugs would be spotted more easily. I think a supported selection mechanism for this would be better than just sticking "CFLAGS+= -fstack-protector" in port Makefiles or make.conf. -- Janne Snabb / EPIPE Communications snabb(a)epipe.com - http://epipe.com/ _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Janne Snabb on 4 Jun 2010 01:30 On Wed, 2 Jun 2010, Dmitry Marakasov wrote: > I'd perfer variables to be named and to work similarily to existing > MAKE_JOBS framework. Me too. Makes sense. The variable names in my original example were intended for illustrative purposes only. > AFAIR there was certain performance penalty with stack-protector, I think the penalty is small enough. I would assume that someone has already made an evaluation on this before turning it on in "make buildworld". I was earlier trying to search for a discussion on it, but I did not find it on the public mailing lists. Maybe it is somewhere. > It may be implemented by mere copypasting MAKE_JOBS implementation, > like this: http://people.freebsd.org/~amdmi3/stack-protector.patch It looks good to me. Simple enough. It would be nice to see this committed. > Also note, that unlike MAKE_JOBS (for which build failures are > non-deterministic), this can probably be tested with a single exp-run > and all ports marked with STACK_PROTECTOR_{UN,}SAFE. If that's > considered useful enough as well. STACK_PROTECTOR_UNSAFE could be automatically added in many cases where it is needed (if either the port itself or if something that depends on it fails). But based on my experience, STACK_PROTECTOR_SAFE should not be added based on a mere build check. I remember that some ports built fine but the resulting binaries would not work for various reasons when I did my CFLAGS+=-fstack-protector experiment a couple of months ago. Unfortunately at that time I did not keep a record of which ports were problematic (and I built && tested only a small subset of ports which were the most relevant to myself, most of them being network facing server programs). IMHO there should be some sort of human testing effort to mark ports STACK_PROTECTOR_SAFE, to which I could certainly contribute. One question is: does it make sense to send-pr this information for each port, or should the testing results be communicated through some alternative channel so that the gnats will not be overwhelmed by PRs related to this (the total number of ports is quite high). Before starting human testing for STACK_PROTECTOR_SAFE an automatic test and flagging for STACK_PROTECTOR_UNSAFE is needed. Otherwise too much of the testing effort goes to marking UNSAFEs which can be easily determined with an automated test. -- Janne Snabb / EPIPE Communications snabb(a)epipe.com - http://epipe.com/ _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: "b. f." on 5 Jun 2010 17:53 Janne Snabb wrote: >> AFAIR there was certain performance penalty with stack-protector, > >I think the penalty is small enough. I would assume that someone >has already made an evaluation on this before turning it on in "make >buildworld". I was earlier trying to search for a discussion on it, >but I did not find it on the public mailing lists. Maybe it is >somewhere. .... >I remember that some ports built fine but the resulting binaries >would not work for various reasons when I did my CFLAGS+=-fstack-protector >experiment a couple of months ago. Unfortunately at that time I did >not keep a record of which ports were problematic (and I built && >tested only a small subset of ports which were the most relevant >to myself, most of them being network facing server programs). This is not the first time that this issue has come up. Jeremie Le Hen pushed through the integration of stack protector support with the help of others. If I recall correctly, his original tests showed ~2-5% penalty for the time required for buildworld. (Unfortunately, his original website has disappeared.) This was thought to be acceptable, and the added security (the stack protector can be circumvented, but it is much better than nothing at all), and the fact that it makes finding buffer overflows a bit easier, were thought to be good reason to enable it by default in most of the base system. I thought that the ports committers would then clean up the ports so that it could be used for the majority of them, too, but this didn't happen -- even though there are outstanding problems arising from the fact that stack protection is enabled by default in the base system of some supported versions of FreeBSD, but not in ports. I've been building most of my ports with stack protection since 2008, and most of the failures (~15 of my ~450 installed ports needed to be patched on i386, and far fewer on amd64) arose from the fact that many ports don't respect LDFLAGS (the stack-protector flags need to be passed when linking as well as when compiling). This needs to be fixed, and not just for using the stack protector: there has been a lot of interest in the use of alternative compilers and tool-chains in ports, and this will require that most ports respect not only CC, CXX, and CFLAGS, but also CPP, CPPFLAGS, LDFLAGS, AS, AR, ARFLAGS, LD, OBJCOPY, etc. This may be needed to make ports available on other architectures, too. Right now these variables are often ignored (see how many ports don't pass CPPFLAGS or LDFLAGS during configure or build, or pass some value that is hard-coded in the port Makefile), or set to the wrong values in ports/Mk/bsd.commands.mk, ports/Mk/bsd.port.mk, /usr/share/mk/sys.mk, or the port itself. With reference to Dmitry's patch, I don't think that three different overlapping variables are really needed, and there is already a precedent for using "SSP" rather than "STACK_PROTECTOR" in the base system -- for example, WITHOUT_SSP in src.conf, MK_SSP in a number of places, and SSP_CFLAGS in /usr/share/mk. Also, note that support for the stack protector in the base system, which may affect support in ports, is not available on several architectures, and can also be disabled by users in src.conf (see, for example, /usr/share/mk/bsd.sys.mk). b. _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
|
Pages: 1 Prev: LPRng installation error using PORT_REPLACES_BASE_LPR Next: DosBox upgrade failed. |