Run-time bounds checking can work reliably, yes. Compile-time
bounds-checking -- well, it *could*, but it would be impractical. I
was talking about compilers that insert reliable run-time bounds-checks
into programs, like the recent modifications to gcc.
> > What I meant was that there are (many!) other security bugs that are
> > not the result of wild pointers, and so you can't rely on your compiler
> > to catch them.
>
> That is also true. It may be harder to imagine a bug which makes
> a suid root program fall over and spew garbage all over /proc/kmem, but it
> is not impossible. Should the kernel watch for this? No, it assumes that
> suid root code knows what it is doing. That means no special treatment.
Janus is another interesting approach. You can run your suid-root code
under a monitor which knows, for instance, that the only thing `named'
is supposed to `execve' is `named-xfer', and denies any other `execve's
from named.
> I think you could say that if the stack-smashing thing isn't a problem for
> non-root code, it just plain is not a bug period, at least not in the same
> sense.
I don't know. Bugs are relative to requirements; if a program meets
its requirements perfectly, then it has no bugs. If my requirements
for a non-root program do not include reporting errors when too-long
inputs are given (that is, "Segmentation Fault" is an acceptable error
message), then buffer-overflows aren't necessarily bugs.
Kragen
-
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