Date: Sat, 19 Apr 2008 11:37:01 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: Garance A Drosehn <gad@FreeBSD.org> Cc: Max Laier <max@love2party.net>, freebsd-arch@FreeBSD.org Subject: Re: Integration of ProPolice in FreeBSD Message-ID: <20080419093701.GJ4840@obiwan.tataz.chchile.org> In-Reply-To: <p0624080bc42eebc490b9@[128.113.24.47]> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <p0624080bc42eebc490b9@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Fri, Apr 18, 2008 at 08:37:24PM -0400, Garance A Drosehn wrote: > At 10:47 PM +0200 4/18/08, Jeremie Le Hen wrote: > > 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. Honestly, the really painful part when reverting this patch was the disappearance of SSP symbols from libc. But I think this will never happen because they have already been in libc for about a year. Enabling/disabling SSP should not hurt. > 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. On Sat, Apr 19, 2008 at 05:14:00PM +1000, Peter Jeremy wrote: > I would agree that a phased approach to enabling SSP is warranted but > I believe it should wind up enabled by default in -current fairly > rapidly. Once the Project has gained more familiarity with SSP and > its > impacts, a decision can be made as to whether it should default to on > or off in -stable and releases. Provided the very little performance overhead [1], my leaning goes toward Peter here. Moreover given that some ports simply don't compile with SSP (qemu, gcc4, etherboot), my personal opinion is it should be enabled by default for ports on -CURRENT in order to spot those out. Note that the port bits have not been provided yet, I will contact portmgr@ for this. [1] http://www.trl.ibm.com/projects/security/ssp/node5.html Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080419093701.GJ4840>