Khimenko Victor <khim@dell.sch57.msk.ru> writes:
> On 8 May 2000 yoann@mandrakesoft.com wrote:
[snip]
> > > > It does not work.
> > > > Please read the 'Proposal LUID' and 'Security in general (was Re: Proposal "LUID")'
> > > > threads, where this was highly discuted.
> > > >
> > > This discussion does not apply here. Not at all. There was discussed some
> > > things to be done in PUBLIC (read: intruder aware about changes). If you
> > > are doing EXACTLY some thing in secrecy it'll work for some time (may be
> > > even not so short time).
> > >
> > > Please, please, PLEASE try to understood that "does not work as long term
> > > solution" and "does not work at all" are different things. Sometimes
> > > DRASTICALLY (for example UUIDs are always used as unique things but still
> > > in REALLY long term they are not: there are only finite number of
> > > different UUIDs :-))
> > >
> >
> > non executable stack give, as it was said before, a false sence of security;
> >
> And guess who said it ?
many people including me.
>
> > also, the majority of recent exploit work on non exec stack as it is, at least,
> > as easy to write an exploit for non executable as for executable stack.
> >
> Hah. HOW LONG non-executable stack prevented exploits for quite a few
> peoples ? Yes, it's well-known thing now and does not work anymore.
> That's why you do not want such things in mainstream kernel.
>
> > So it will not even work on short term.
> >
> It works fine in short term. Non-executable stack prevented LOTS of
> intrusion attempts. Yes, now this hack timed out and not so usefull
> anymore but it worked. For few YEARS. Not so "short" term I want to say.
You said it ! :)
<quote>now this hack</quote>
Yes, this is a hack, and this does nothing except bloating your kernel.
There is already some user space tool / library which allow you to prevent
your system against stack overflow, libsafe is a good exemple :
http://www.bell-labs.com/org/11356/libsafe.html
-- -- Yoann http://www.mandrakesoft.com/~yoann/ It is well known that M$ product don't make a free() after a malloc(), the unix community wish them good luck for their future developement.- 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 : Sun May 07 2000 - 21:00:21 EST