Robert Dinse <nanook@eskimo.com> writes:
> 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.
Ever heard about bound checking ?
> I can't use Stackguard on most of my machiens, because it is specific only
> to x86 and also to old versions of gcc.
At least, you can use libsafe on x86 machine.
> Someone here mentioned safelib's which I am not familiar with and would
> like to know more about.
search for libsafe on freshmeat.
[...]
> The Solar Design patch offers a few more layers.
yes, and non executable stack is really *not* a part of theses layer.
> 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.
<rant>
Now you're suggesting that people involving in some threads on lkml
are saying bullshit and do not know what they are talking about;
i've not seen any piece of code from you nor kernel nor user space...
i don't care, but if you think that what was said in such thread
is bullshit :
<quote>
The majority arguing agaist it seem to not
understand this very fundamental point.
</quote>
Or you didn't read the good thread
or you're simply an idiot.
</rant>
>
> 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.
That's not the problem,
non exec stack wasn't accepted because it give a false sence of security.
>
> 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.
Yes, and bloat the kernel code, which is really the last thing to do.
--
-- Yoann, http://www.mandrakesoft.com/~yoann/
It is well known that M$ products don't call free() after a malloc().
The Unix community wish them good luck for their future developments.
-
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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:12 EST