Date: Sun, 30 May 2010 06:49:16 +0000 (UTC) From: Janne Snabb <snabb@epipe.com> To: freebsd-ports@freebsd.org Subject: Re: Building ports with stack-protector Message-ID: <alpine.BSF.2.00.1005300537400.22303@tiktik.epipe.com> In-Reply-To: <AANLkTikx2NRN2qsj_-uyzOl0zL7efc_klp090XoFlq9W@mail.gmail.com> References: <alpine.BSF.2.00.1005300201380.22303@tiktik.epipe.com> <AANLkTikx2NRN2qsj_-uyzOl0zL7efc_klp090XoFlq9W@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@epipe.com - http://epipe.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1005300537400.22303>