[cap-talk] BitFrost : OLPC Security Architecture

[David Hopwood]

Stiegler, Marc D wrote:
> The indication that someone involved has seen and remembered at least
> some portion of our stock presentation is this passage, oddly placed in
> software installation:
> 
> 399 To provide an example, consider the Solitaire game shipped with most versions
> 400 of Microsoft Windows. This program needs:
> 401
> 402 * no network access whatsoever
> 403 * no ability to read the user's documents
> 404 * no ability to utilize the built-in camera or microphone
> 405 * no ability to look at, or modify, other programs
> 
> Hmmm....the solitaire program as an example of limited authority
> requirements...hmmmm...:-)

Yes, we're clearly having some influence.

> There are nonetheless things that make me despair, as the preface to the
> solitaire example: 
> 
> 379 There is a very important distinction between two broad classes of programs
> 380 that execute on a running system, and this distinction is not often mentioned
> 381 in security literature. There are programs that are purposely malicious,
> 382 which is to say that they were written with ill intent from the start, such as
> 383 with viruses and worms, and there are programs which are circumstantially
> 384 malicious but otherwise benign, such as legitimate programs that have been
> 385 exploited by an attacker while they're running, and are now being instrumented
> 386 to execute code on behalf of the attacker via code injection or some other
> 387 method.

To be fair, it's necessary to be aware of this distinction in order to
reason correctly about what security properties can and cannot be provided
by code authentication. The OLPC will need code authentication, in addition
to supporting POLA for all programs.

> 388
> 389 This difference is crucial and cannot be understated,

I think the author means "cannot be overstated", although they do overstate it.

389 This difference is crucial and cannot be understated, because it's a
390 reasonable assumption that most software running on a normal machine starts
391 benign. In fact, we observe that it is through exploitation of benign software
392 that most malicious software is first _introduced_ to many machines, so
393 protecting benign software becomes a doubly worthy goal.
394
395 The protection of benign software is a keystone of our security model. We
396 approach it with the following idea in mind: benign software will not lie about
397 its purpose during installation. [...]
...
420 The critical observation here is not that Solitaire should never have the
421 ability to do any of the above (which it clearly shouldn't), but that its
422 creators _know_ it should never do any of the above. It follows that if the
423 system implemented a facility for Solitaire to indicate this at installation
424 time, Solitaire could irreversibly shed various privileges the moment it's
425 installed, which severely limits or simply destroys its usefulness to an
426 attacker were it taken over.

The general approach here is reasonable -- in fact similar to suggestions made
on this list recently -- the motivation is just poorly explained (and it's not
clear whether or not the author really understands it).

The value of
 a) protecting the integrity of software (making it read-only and cryptographically
    authenticated);
 b) giving it no more authority than it asked for;

does not depend on any particular piece of software being benign. a) and b) can
and should be done for all software, regardless of how benign or malicious it is.
It doesn't matter (even if it doesn't have any benefit) that we do a) and b)
also for malware.

This is important since the system *doesn't know* which software is benign and
which is malicious -- not even when it is cryptographically authenticated.

Of course it's also essential that authority can be granted (e.g. via trusted
'open' dialogs) after installation. The document does mention that later on,
at line 884:

884 Programs on the XO may not use the open() call to arbitrarily open user
885 documents in the system, nor can they introspect the list of available
886 documents, e.g. through listing directory contents. Instead, when a program
887 wishes to open a user document, it asks the system to present the user with a
888 'file open' dialog. A copy-on-write version of the file that the user selects
889 is also mapped into this scratch space -- in effect, the file just "appears",
890 along with a message informing the program of the file's path within the
891 scratch space.

This seems quite similar to the Polaris implementation. The devil is in the
details, though.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>