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

    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

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.044 / U:34.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site