lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.198 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site