That's with the broken assumption that you couldn't root the system
without the no-stack-exec patch.
Yes, it may be harder, and yes, it may take longer, but you're assuming
that the kernel patch is somehow a fix for the bug, and it isn't. It's at
best a bandaid.
Quite frankly, I'd personally be much happier with having a few systems be
"rooted", and get the application fixed properly as a result, than have
some bandaid that _almost_ fixes the problem.
The thing is, that if there are known exploits (the ones floating around
in the hacker community), there is _no_ excuse for not fixing those bugs.
As a result, there is _no_ excuse for having a system that is vulnerable
to being rooted by old and known exploits.
And yet, the arguments that people have had in favour of no-stack-exec is
that it protects you against these well-known exploits - and that hackers
are too stupid to come up with new ones.
You can't have it both ways. Either the problem is old exploits (in which
case the kernel hack is just plain wrong, as the real bugs are also
known), or the problem is new exploits that haven't been used yet (in
which case the kernel hack is not sufficient protection anyway).
Yes, the kernel hack can protect you against a limited form of old-style
but not yet known exploits. However, I still claim that it's better to
find them the hard way rather than not find them at all, and I also claim
that making the no-stack-exec patch the default wouldn't help anyway,
because it would just mean that the crackers who _do_ come up with new
ideas would take it into account by default, and then the protection is
also zero.
The ONLY reason I see for the kernel hack is to allow people to ignore
certain known security holes in user space. And that's a really bad reason
in my book.
So I don't mind people maintaining the thing as a separate patch - that's
what having sources available is all about: freedom. However, I also
personally think that it is a bad thing to have in the kernel, and I won't
accept it in the tree _I_ maintain until somebody can come up with better
arguments than I've heard so far.
Linus
-
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.altern.org/andrebalsa/doc/lkml-faq.html