Re: [friam] SOSP History Day

On 2015-10-12 20:06, Lorens Kockum wrote:
> On Mon, Oct 12, 2015 at 08:16:09AM -0500, David Nicol wrote:
>> Square root having authority to delete files, were the library
>> compromised, is an excellent example.
> 
> It is a good example when you wish to narrow it down as far
> as possible, but it is a little far-fetched when you wish to
> explain capabilities to neophytes. In the case of sqrt, either
> you have installed a malicious system library, or someone
> untrustworthy is launching your authority-carrying (setuid...)
> binary and linking it with his malicious library.
> 
> A more reasonable example would be something that is not
> always installed with the system and often updated, such as a
> third-party statistics package, or even better a video player
> or a PDF reader. Those don't even have to be malicious, just
> too complex and vulnerable to malicious input, and there are
> multiple real-world examples of such problems.

Trojans and Trojan components are about 'how do I run untrusted code?' 
while
bugs in the square root functions are about 'how do I reduce trusted 
code?'.

Capabilities may answer both questions in the same way, but the 
difference
between the questions is important. There is a widely spread 
misconception that
avoiding bugs and patching speed are what matters. I think the square 
root example
is an excellent example in that sense. In a large code base its likely 
that a square root function will be skipped or missed when doing a 
limited resources security oriented
code review. How does it handle negative numbers? Oops, that code wasn't 
tested properly and instead of invoking ComplexNumber::Init() on an 
instance of RegularNumber, it ends up calling
the global Init() function without parameters, resulting in the program 
config file being overwritten with an empty default config. No arbitrary 
code execution, no untrusted 3th party code, just a piece of rarely used 
code-path that had a hidden accidental dependency.

Its basically all about reducing the trusted code-base. There should be 
no reason why we should need to trust square root to not mess with our 
config file unless we hand it a reference to our config file or 
something that allows it to obtain such a reference explicitly. We 
should only need to trust square root to give us a valid response 
derived from the const reference to the operand we supplied it with. Any 
possibility for non-explicitly injected dependencies of a piece of code 
promotes that piece of code to our trusted code-base, turning any 
security review into a black hole for limited time resources.