[1]On Tue, 04 Aug 1998, Linus Torvalds wrote:
>I chose libc mainly because it's the obvious choice, but your example
>makes it just all the more clear that the whole approach of the patch is
>not to fix real problems, but to fix specific attacks that really should
>have been fixed in the binary.
Can you please define 'real problem'?
[2]On Wed, 05 Aug 1998, Linus Torvalds wrote:
>In short, my argument is not that the kernel should not try to make things
>secure for you. My argument is that no-stack-exec adds nada, zero, zilch,
>nothing in the form or real security.
I agree with you completely that the no-stack-exec patch provides a marginal
security of exactly zero. However, UNIX is broken with respect to security _by
design_, and _already is_ full of various ad hoc solutions that try to solve
individual security related problems.
The particular problem of stack smashing is an example of a security related
problem that, in the existing paradigm, _cannot_ be fully and cleanly solved.
The right solution for this particular problem is to enable building of objects
that support the principle of least authority - when an object only contains the
authority to manipulate a string in a page of memory (but not also the authority
to spawn a root shell), the stack smashing problem is no more. So, the solution
is easy: build the system from small, highly specialized objects that each
contains an insignificant amount of authority, such that in case of a buggy
object the attacker can't get sufficient power to do anything really bad, thus
limiting the damage that can be done by exploiting such a buggy object.
Unfortunatelly, UNIX systems, including Linux, are _by design_ (and by choice
since we prefer to keep the system fast (but insecure) on a crappy architecture
like x86, where (among numerous other deficiencies) border passing is slow,
instead of making it a bit slower (but at least secure) on crap but fast (and
also secure) on better architectures - this is not Windoze, we can actually
CHOOSE what we want to run our applications on, can we?) made of _large_
objects that, by definition, _cannot_ support the forementioned principle. So
the only solution that can at all exist in such an environment is an ad hoc one
that will only partially solve the problem.
The no-stack-exec patch is such a solution. And it does try to solve a _real
problem_. It's not a complete one, but it's the best one there is at the moment
and probably the best one there ever will be for this particular problem in
this particular type of environment.
[3]On Wed, 05 Aug 1998, Linus Torvalds wrote:
>Or sombody had better tell me why they shouldn't fix their broken
>applications.
You can run away from the problem by telling other people that they should fix
it for you by fixing their applications. You can't hide from it though, since
it's the _kernel's_ job to protect the system in the first place, and this
being the case, the solution (whatever it may be) _belongs_ into the kernel. If
you want a secure system, you can't let a broken application compromise it. You
know that, because that's one (of many) of the reasons why we use protected
memory.
[2 cont.]
>No, you may not be open to old exploits if you have the no-stack-exec
>patch. But old and known stack exploits aren't the issue:
Basically, there are three options available: to ignore the problem and hope
that it will go away (which it won't); to implement an ad hoc solution, such as
the no-stack-exec patch, that at least partially solves it; or to change the
paradigm upon which Linux is built, thus making the stack smashing problem go
away forever.
Since future and unknown stack exploits are the issue, what solution do you
suggest we implement?
In the short run, I would (if I may) recommend a config option for the
no-stack-exec patch. For a few simple reasons: it's has been and _is_ being
used by people who consider stack smashing to be a _real problem_, it is known
what problems it cures, what problems it doesn't and what problems it creates,
so people can work on them, and it's the best solution for the problem that is
available _now_.
But in the long run... Well, I guess that in the long run, the choice is still
yours.
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si- 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