[langsec-discuss] composability

travis+ml-langsec at subspacefield.org travis+ml-langsec at subspacefield.org
Thu Jan 21 04:18:59 UTC 2016

On Wed, Jan 20, 2016 at 07:38:30PM -0800, travis+ml-langsec at subspacefield.org wrote:
> I am having trouble imagining the case where adding security
> boundaries decreases security, except for the case Guthrey implied,
> where a layer/module/system relies on another layer/module/system for
> a security-relevant decision, and has (worst case
> adversary-controlled) choices of same, in which case you get a
> "weakest link" security = min-security.

Actually, I take that back:

The correctness problem is clearly dependent on complexity, but for a
given complexity, I'm not convinced that LMC is inherently bad - quite
the contrary.  We had a word for poorly-modularized code, and that was
"spaghetti code".  Having everyone write all the software stack
doesn't benefit from scrutiny the way a battle-tested library does.
My developers are not likely to match the ZeroMQ guy*, especially if
they to write an MQ implementation and code something which relies on
it (and has a completely different purpose) at the same time.  That
reduces focus.

[*] http://250bpm.com/blog:4

Conversely, for a decision based on other decisions, the correctness
calculus is such that the chance that one of them is incorrect (at
least for some inputs) increases, due to
1) distribution of quality among the decision software layers
2) "impedance mismatch" & misunderstandings between layers/APIs/contracts
3) bit rot of layers and contracts

This is a fascinating case study of same:

TL/DR: it's complicated.  Sorry to think out loud.
http://www.subspacefield.org/~travis/ | if spammer then john at subspacefield.org
"Computer crime, the glamor crime of the 1970s, will become in the
1980s one of the greatest sources of preventable business loss."
John M. Carroll, "Computer Security", first edition cover flap, 1977

More information about the langsec-discuss mailing list