sbg at acw.com
Sat Jan 9 19:04:27 UTC 2016
At the dawn of serious thinking about programming there was the notion of information hiding. The given wisdom was that all you were supposed to know about a programming interface was what each entry point did. In particular, you were to be explicitly precluded from knowing how each entry did whatever it did. A tenent of good API design held that this information was to be hidden from the user of the interface; thus, information hiding was regarded as a Good Thing. The primary justification for this API design rule was that the provider of the API could change the how without disturbing the what and hence not ripple the code using the API.
In the event, very few hows were ever actually changed and needed information not found in documentation of the entry points leaked. Consider, for example, a square root entry point. The documentation says you give it a positive number and it gives you back a number that when multiplied by itself is almost the number you give it. Now, suppose I want to add up a bunch of square roots. I care if the approximation is equally likely to be too big as to small so that my sum stays close to the actual sum of the square roots. If the approximation is always too low or too high my sum drifts away from the actual sum. The information I need is hidden from me by good API design so I conduct experiments against the entry point. Once I figure out a property of the how I want to use what I’ve discovered but now don’t want the designer to change the how.
You can see how this leads to all sorts of excess code in the interest of correctness. I don’t know what I need to know about what’s down there so I have to constantly check to make sure it’s behaving the way I need it to behave. Or, I just do it myself and don’t use the API. I’d be willing to bet that at least ... pick a number ... 1/3 of the code in large systems (think an ObamaCare connector) is unnecessary. This bloat is can be at least partially attributed to information hiding.
The point of all of this is to agree with Dan’s “yes” intuition. Set aside crypto. Set aside buffer overruns. Set aside all the other little programming gotchas we worry about for the moment. How do we put code together? My programming experience (which started in the mid 1950’s) tells me that the composition of N>1 known-secure components is more likely than not to be less secure than the least secure of lot because they are all running --- wittingly or not --- on unjustified assumptions about what the others are doing.
I don’t have a silver bullet. (The Lone Ranger stole it.) But I do believe that insufficient LANGSEC attention is given to the impact on end-to-end security of the way code is composed.
There is a reason that Knuth wrote V1.0 of TeX as one monolithic program. It wasn’t for security. It was for understanding.
IMHO, as always.
From: dan at geer.org
Sent: Friday, January 08, 2016 9:19 PM
To: langsec-discuss at mail.langsec.org
Subject: [langsec-discuss] composability
So far as I know, security is not composable, which is to say
that there is no reason to expect that the connection of N>1
known-secure components is itself secure in the aggregate.
But as an honest question, could or would the broad deployment
of LANGSEC diligence help with that problem of composability?
My intuition is "yes, it could or would help" but it is only
intuition, not a deduction.
Were it possible to persuasively show that diligent LANGSEC
work would help with composability, then the demand for that
diligence might grow quite strong.
Thinking out loud,
langsec-discuss mailing list
langsec-discuss at mail.langsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the langsec-discuss