[cap-talk] Hybrid Cap Systems redux

[David Wagner]

Jonathan Shapiro writes:
>Two problems here:
>
>  1. C is unsafe, therefore these safety checks violate C semantics (and
>     do so in practice, not just on paper).
>
>  2. It is a continuing source of wonder to me that people think it is
>     good to induce failure in working C programs by adding checks that
>     cause perfectly good programs to fail.
>
>It isn't good enough to guarantee that misbehaved programs fail. What we
>need is to guarantee that programs do not misbehave.

Can you explain these two comments?  If you mean something more
than "safety checks alone are not sufficient", I'd like to understand
what you mean.  I know you've thought about this a lot and so I suspect
you may be hinting at something non-obvious...

Here are my reactions to your comments:

  1. Safety checks, like checking that array dereferences are in-bounds,
     do not violate the C spec.  The C language spec allows compilers to
     perform array bounds checks, though that is obviously not required.
     If the program is writing out-of-bounds, then it has "undefined
     behavior" (a term of art in the C spec), which means that the
     compiler is free to do anything at all that it wants -- including
     terminate the program.

  2. If the program is writing out-of-bounds, it's probably not a
     "perfectly good" program; there is a significant chance that
     the program has a security vulnerability.  Therefore, I'd think a
     better way of describing this would be to say that it causes flawed
     and quite possibly vulnerable programs to fail.  You're right that
     there may be some programs which write out-of-bounds (and thus are
     very poorly written) but just happen to work and just happen not
     to be vulnerable, and adding safety checks will break those poorly
     written programs.  In many cases, that's an acceptable tradeoff.
     I don't understand your source of wonder.

Of course safety checks are not the full answer; they are an imperfect
mitigation for a legacy problem.  The mitigation may not be "good
enough" to fully solve the problem, but it's better than nothing.