[langsec-discuss] Tainting input for better security

Michael E. Locasto locasto at ucalgary.ca
Fri Jun 15 12:46:01 UTC 2012

Hash: SHA1

> It always will -- the key is to separate, encapsulate and validate 
> the boundaries between systems, so that they protect and border
> and greet each other.

As a clean-slate design principle, I'm all for this. I think I'm
suggesting that composing or putting to systems together (and this may
be as simple as having them communicate via a file or FIFO) makes the
task of continuously drawing that boundary difficult. In the extreme,
the boundary is scattered at various unpredictable levels of control
flow in the new, composed system.

(as an aside: I think a common error pattern here is to "forget" to
perform parameter checking on function inputs because one believes
that this method will never ever be called by any other than a small
set of other methods, but then this assumption becomes false when
someone else decides to exercise that wonderful thing called code reuse.)

Strongly typed mechanisms, as you point out, have the benefit of doing
some basic implicit checking on data at each and every point of its
use. But it seems to me that even this validation is somewhat limited
in power and leaves the door open for vulnerabilities arising in the
logical rather than lexical interpretation of the data.

> That sounds about right.  I really wish that Parnas's talks on 
> encapsulation were required reading by all undergrads...

Sounds like a nice link for the langsec website...

Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the langsec-discuss mailing list