Date: Sat, 19 Apr 2008 14:47:24 -0400 From: Garance A Drosehn <gad@FreeBSD.org> To: Jeremie Le Hen <jeremie@le-hen.org> Cc: Max Laier <max@love2party.net>, freebsd-arch@FreeBSD.org Subject: Re: Integration of ProPolice in FreeBSD Message-ID: <p06240800c42fec6eb93f@[128.113.24.47]> In-Reply-To: <20080419093701.GJ4840@obiwan.tataz.chchile.org> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <p0624080bc42eebc490b9@[128.113.24.47]> <20080419093701.GJ4840@obiwan.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:37 AM +0200 4/19/08, Jeremie Le Hen wrote: > >On Fri, Apr 18, 2008 at 08:37:24PM -0400, Garance A Drosehn wrote: > > >> 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. My comment was talking about how we would roll out SSP for *releases*. I do agree we'd move faster for having developers test it in -current. >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. This part I'm not so sure of. The fact that I'm willing to run freebsd-current to test *freebsd* changes does not mean that I want to be constantly tripping over port-specific problems. I realize that SSP is certainly useful for ports, but that's > 15,000 programs which we probably have little control over. It's going to take quite awhile before we get that sorted out. I guess I don't have any specific recommendation for how to handle SSP in the ports collection. Maybe per-port settings, although that would also get messy. The main ports-developers should decide how SSP should be rolled out through the ports collection. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06240800c42fec6eb93f>