Messages in this thread | | | Date | Mon, 3 Jul 2000 05:07:14 -0700 (PDT) | From | Robert Dinse <> | Subject | Re: Low Latency Patch |
| |
On Mon, 3 Jul 2000, Horst von Brand wrote: > > > Perhaps you run all the stock binaries on these distributions, I do > > not. > > I don't run stock binaries either, but most people do. Compilation flags > and most version skew won't ordinarily affect the placement of buffers in > stack frames anyway, so this at most buys you a tiny bit of extra security. > And adding a patch to the mainstream kernel so people like us are safe > (even if it was so in this case, which I very much doubt) while hurting > everybody else for nothing should not be an option. Ever.
Something that would randomize the placement of the buffers in combination with a non-executable user stack area would make the exploit considerably more difficult.
Security is an issue that needs to be addressed, and I personally don't believe any one thing can address it. You do everything you can do.
I do review code, and I've found and fixed some exploits but I've also missed some. Unless fundamental changes are made to C and the standard libraries, people are going to continue to write bad code. Functions that write to buffers with no bounds, like gets() should be allowed to exist.
I try to find ways not to run anything as root that can possibly be run without root priviledges, and relative to say the way RedHat is distributed, very little on my boxes need or run with root priviledges, but still some things do.
I use fairly extensive filtering and don't put a lot of services on any given box.
I can't use Stackguard on most of my machiens, because it is specific only to x86 and also to old versions of gcc.
Someone here mentioned safelib's which I am not familiar with and would like to know more about. I do presently use securelib's to limit unauthorized access to RPC services. I also use a replacement portmapper for the same reason. Just about all TCP and UDP services are wrapped to limit access.
The list goes on. The point is you just can't do too much. Absolute security is unobtainable, but if you make your house more difficult to break into than your neighbors, chances are the burgler will pick your neighbors, unless he's just some psycho-weirdo that likes a challange.
The Solar Design patch offers a few more layers. It is not mutually exclusive with other security measures. Yes, I did follow the argument so do not point me at the archives. The majority arguing agaist it seem to not understand this very fundamental point.
I know Linus doesn't like ifdef's and I do actually understand that it makes the code very difficult to read and understand because you've got to know the state of a few dozen defines to know what code is being included or excluded.
But these capabilities shouldn't be ignored either. Maybe a fix would be to include them in the kernel aways and turn them on or off with something in /proc/sys so there are no ifdef's involved.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |