Integration of ProPolice in FreeBSD

[Garance A Drosehn]

At 10:47 PM +0200 4/18/08, Jeremie Le Hen wrote:
>On Fri, Apr 18, 2008, Max Laier wrote:
>
>>  2) Add support to build kernel/world with SSP enabled - default OFF.
>>  3) Solicit testing!
>  > 4) After some time has passed (and people have had to reinstall
>  >    libc anyways), and enough feedback has been received flip the
>  >    switch to default ON.
>
>I will change my patch to make SSP opt-out.  This will address
>Marcel's concern too.

This is a big-enough change that we should ease into it, as Max
suggests.  It can be very painful to back out of this, so we don't
want to rush into the change and then find out that we really
really regret it.

>  > In light of the the recent "let's save stack space in the kernel",
>  > I'd like to point out that SSP adds one word to every call.  Not
>  > much, but still.
>
>Certainly.  I would like to hear opinion from other committers if
>SSP should be enabled by default.

You've probably described this somewhere, but let me ask for a little
more info.

There is "enabled" in the sense that the symbols exist in libc, so
programs *can* be compiled with -fstack-protector-all or
-fstack-protector options.  But nothing much really happens until
we start building programs with those options turned on.  Once a
program is built with one of those options, then that program has
code in it which will check for stack-smashing in that one program.

So, in my mind there's the step of "enabling SSP", and then there's
the step of "compiling programs with stack-protection on".  I think
we could also split that the second step in stages:

   a) add stack-protection to all setuid programs in the base system.
   b) add stack-protection to all "/usr/sbin" programs in the base.
   c) add stack-protection to all programs in the base.
   d) compile ports with stack-protection on.

Is that a reasonable breakdown?  We could (perhaps) have four
switches, and people could turn on whatever wants they wanted.  But
as far as the *default* values, we might want "class A" to default
on for 8.0-release, but the other classes to default off.  Then
(maybe) add another class each time we make another release.

-- 
Garance Alistair Drosehn     =               drosehn at rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA