On Thu, Nov 12, 2009 at 10:05:07PM -0500, Steven Bellovin wrote: > > On Nov 12, 2009, at 8:45 PM, Elad Efrat wrote: > > > On Thu, Nov 12, 2009 at 6:58 PM, David Holland > > <dholland-current%netbsd.org@localhost> wrote: > >> On Thu, Nov 12, 2009 at 03:30:23PM -0500, Elad Efrat wrote: > >>>> After protests from multiple developer because of the performance hit > >>>> I've reverted the changes. SSP is now off by default (except for > >>>> library and network daemon builds) on all platforms, in particular > >>>> for NetBSD/amd64 and NetBSD/i386 kernels. > >>> > >>> Unfortunately for rmind@, pooka@, and haad@, until proven otherwise, > >>> it seems more developers are interested in having SSP enabled by > >>> default. Please put it back. No developers are more equal than others. > >> > >> I don't see that there's a convincing rationale for turning it on in > >> the kernel. > > > > Unfortunately for you that does not change the situation one bit. > > > > However, for pure fun, let's look at the "rationale" here. If your > > kernel is built without SSP and a vulnerability that it might have > > protected against is being exploited, there's a fairly good chance > > that it will result in either stack corruption leading sooner or later > > to a panic, or to a kernel compromise. (Not root compromise -- there's > > a very big difference.) > > Before we had plists in the kernel, I wasn't as worried. We have them now. And now the proplib FUD. That kind of blanket statement from such a respected security professional is just sad. You're worried you have plists? You've had ioctls almost forever! And yes, I'm just throwing that like that. Go and stop me. Like other people, I am concerned by the 5% penalty. And to me it seems that all the people favoring setting USE_SSP to yes for the kernel only have to offer that the user can re-compile his kernel. Well, guess what? It works either way. Of all the NetBSD machines I have, some of them will have a use for those 5%, and I'll grant you that some will be just fine hypothetically crashing instead of hypothetically falling into the evil plans of an hypothetical overlord because of an equally hypothetical bug. In the end it is a question of balancing the defaults, but, before anyone even suggests it, provinding two kernels is completely out of question. I am ambivalent on the question of the default of USE_SSP. But it's not because of the removed insecurity it provides, or the marvelous (and recent) fastestness of the NetBSD kernel. It's more a debate that goes like, on one hand, we have people who really care about security. Will they really use a kernel they didn't compile, even provided by TNF? Will they really use the kernel TNF provides (hello, modules!)? Yeah, right. But then, let's be honest, the situations were the 5% performance gain actually makes a difference are few and far between, and people in such situations might want to use different compilation options for their kernel anyway. I can think of one situation where the 5% performance gain does make a difference, though. When some lame ass blogger does a poorly operated benchmark of, say, NetBSD 6.0, 5.0 and whatever will be the greatest Linux and FreeBSD at the times, it will go like this: "pfff, those idiots at NetBSD, 5.0 kicks 6.0's ass for performance". And here goes Slashdot and the crowd of cretins. So in the end, I think it's only a matter of hype. Don't get me wrong, but somehow a feature whose only purpose is to mitigate bugs that haven't been found is not a very positive message. An honest one, maybe, but plain honest truth is not necessarily what sells the newspapers. I apologise for the car analogy, but a fast red polluting Ferrari will always bring more readers to the cover of Quatroruotte than a green hybrid. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgpCl8Yl5ADVU.pgp
Description: PGP signature