> [P]rocesses should not be allowed to change anything in their text
> areas once they have started executing.

> (as we know forcing such protection would once and for all and
> forever prevent any and all buffer-overflow bugs from being effective
> exploits, at least for executing foreign code, [...])

I don't think this is true.

Someone (Solar Designer?) wrote a very well-thought-out piece on buffer
overflows versus non-executable stack segments.  One of the very good
points made was that preventing executable stacks must means you have
to find the code segments you want in the executable already - which
there probably are.  Say you have a running-as-root daemon; you
overflow something and make it exec /bin/sh.  Instant root shell - and
you can do it with "/bin/sh" anywhere (eg, in the overflowed buffer)
and the exec syscall where it already is, in libc.  If the daemon calls
exec already, you can do it even with a statically linked daemon.

Besides, drawing a line between code and data is difficult at best and
borderline impossible in some cases.  Shells read scripts into what the
VM system thinks of as their data segments, but treat them,
functionally, as code.  perl and Java p-code engines do likewise.
Anything with an embedded language is exploitable to the extent that
the language is flexible enough to have malware written in it, all
without needing to execute any instructions outside the original text
segment.

Locking down text would raise the bar, but that's all.  It wouldn't
"once and for all [] prevent any [such exploits]".

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B