Ben Reser wrote: > On Thu, Sep 19, 2002 at 08:15:23AM +0200, Giuseppe Ghibò wrote: > >>Well, and if the patch doesn't exists yet? And furthermore I repeat, >>in most cases there aren't ANY sysadmin who worries about upgrades. > > > It exists it just hasn't been kept up to date with the current gcc... > Which I have to wonder why?
Which patch are you talking for? I wasn't talking about StackGuard patch. I was talking of an application/daemon for which could exists a known buffer overrun but not a patch (or the patch has not yet been packaged). What to do in this case? Turn off the machine or the services or hope not being attacked? > I didn't say they > What you're not taking in consideration here is the potential real > problems Mandrake would have in implementing stackguard. Compiling > everything in the distro with it wouldn't probably be an option because > I'm positive there are at least a few things that it wouldn't work right > with. Making it an option to use isn't exactly an easy thing to do > because it's a compile time option. Not a run time option. Mandrake is > already limited on space for new RPMS.... Where are we going to find > the MB if not GB's to put the duplicated RPMS? I'm not saying compiling everything, which IMHO is too much, because for instance there are application where speed is of main importance (e.g. I wouldn't like have the XFree or OpenGL SG enabled, or for instance scientific application like Octave, etc.), but ONLY the MAIN network daemons, and as an option. I.e. when you install them, the installer could ask you: "would you like to install stackguarded version of networked daemons?". You answer yes, they are installed, you answer "no", the standard RPMs (i.e. like the current ones) are installed. How much space could take? 30-40 MBs of duplicated RPMs? Furthermore it's not said it should be in the CDs. Could be an option and the SG daemons could be downloaded from the net, as in the past was done with crypto things. I don't see any difference in doing this and in what currently could be obtained having libsafe enabled (you can disable libsafe <-> you can install regular unstackguarded daemons). > >>If we had based our security to what other distros do, then we wouldn't >>have had any msec, libsafe, kernel-secure, etc. and all our security tools >>would >>have been tcp_wrappers... > > > You're certainly not the only distro shipping libsafe or secured > kernels. And the stackguard patch to gcc isn't exactly new it's been > around for years. There has to be a reason why other distros haven't > adopted it. Or for that matter why Mandrake hasn't adopted it. probably mainly for speed (since we take also a 1-5% gain of speed in consideration, otherwise we wouldn't have had -O3 in %optflags) and because it's not supported on recent [recents means gcc 2.9X at least] compilers (latest SG is of two years ago). > > However the last fear I have about implementing it is that it will make > the very thing worse that you claim is a reason for implementing it. > Patches are necessary with or without stackguard. As I've seen happen Nobody said that with stackguard enabled you'll don't need regular patches: A HUGE BANNER SHOULD SAY IT when you install. It's like saying that since you use the safety belts, you can drove safe everywhere at 250 Kph ala Schumacher. But on the other hand it's better to use safety belts that don't use them at all. On the other hand since you'll probably get a DOS, you have to update anyway. > time and time again firewalls became an excuse for poorly implemented > security. It's not that firewalls don't have a place in a security > regime. It's that many of the newbie type admins you are targeting > your issues to will think that's all they have to do. So indeed I fear No it's targetted to those not doing updates anyway, either because they can't (because the machine could not go down even for 1 second, or because they don't know a bug exists:), either because they don't want. Yes, you could say "You don't upgrade! Your fault, be exploited!!!". > that applying a bandaide (stackguard) and then the ensuing PR/marketing > that will surround it will create a false sense of security. And will > in fact make the problem worse. This seems the old Linus sentence: since the security is not total, better to not use any kind of these schemes and use as only security the relying on regular updates. A "false sense of security" is meaningless: or it protect against a reasonable class of attacks [demonstrated by trying/attempts] (maybe combined together with other protection artifact: kernel, libsafe, etc.) or even a kid can easily defeace it, and in this case is not a protection. > > In the end between the difficulty in implementing this change and the > problems with the attitudes it might create I tend to think it wouldn't > benefit us in the long run. I could be wrong. But that's my opinion. also that was MY, and only MY opinion, which, as always is VERY HUMBLE. > > At any rate though you didn't answer my question. *WHY* have other > distros ignored this. It's not like it's something nobody has known > about (it's been on slashdot at least once). There has to be a reason > for it. Even if it is the attitude fear that I have about it. probably for benchmarking, the other could be that it maybe could CAUSING crashes or because could be easily defeaced (and in this case it would be interesting to see the papers). > > We certainly should take advantage of analysis that other distros have > made of the technology in determining if we should implement it. Don't > you think? > I think that this is important, but also not doing anything on this subject because other distro hasn't yet done this is not the right way. Maybe they are wondering the same of us... Bye. Giuseppe.
