Robert Dinse <nanook@eskimo.com> writes:
> On 2 Jul 2000, Yoann Vandoorselaere wrote:
> >
> > Non executable stack doesn't help preventing stack overflow,
> > that was said thousand of time.
>
> It's said erroneously, because you go from a problem of having to guess
> within a page to having to be exact.
>
> But again, the Solar Design patch does a lot more than just provide for
> a non-executable stack.
here i'm talking about the non exec stack issue,
as Victor said, just consult Lkml archives (the thread
about LUID, and Security in general ) and you'll see explaination
why this is not usefull in order to prevent stack overflow.
>
> > please stop being an asshole.
>
> Please stop being an asshole yourself when you are obviously unfamiliar
> with all the things the patch does.
In vast majority, it append scheduling call all over the place.
> And just because something happens to be
> your opinion doesn't make it right. Even the non-executable user stack area
> does have value.
No they have not, see above ( and look at the thread ).
> The patch also provides restrictions on links in a +t directory, it also
> prevents users from making hard links to files they don't own. This breaks a
> number of race exploits, like the old passwd race, amoung other things.
>
> There are some restrictions on writes to FIFO's in +t directories unless
> the FIFO is owned by the user or the FIFO is opened without the O_CREAT flag.
>
> There is the ability to restrict access to proc, for applications where
> you do not want one user from watching another, ps only shows a users own
> processes, etc.
>
> There is an option to destroy shared memory segments when not in use.
>
> There is a provision for priviledge IP aliases. Not real useful for what
> I'm doing but for someone that runs everything on one box it could have some
> real utility.
I know that and this is true, but here, i'm talking about non exec stack issue
( you just have to find the system() system call vector and pass whatever
string to it (see the thread for more detail) ).
-- -- 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 development.- 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:10 EST