[OLPC Security] Questions on activity signing and upgrade. (Some answers to follow later.)

[Michael Stone]

Dear devel@ and security@,

Scott asked me to spend some time thinking on the topic of activity
signing [1] in the context of activity upgrade [2, 3, 4]. Since I have
some previous thoughts on this subject already available [5, 6], I will
concentrate on new thoughts in this thread. Please enjoy my questions
and offer your own thoughts; I will offer more of my own as I succeed in
organizing them.

Purpose
-------

We have constructed (part of) an isolation system [7] to segregate some
programs run by our human operator from that person's full digital
agency ("power to commit side-effects"). Unsurprisingly, it is
occasionally necessary or convenient to give programs a larger share of
the human operator's authority than they would be granted by default.
Therefore, given that such privileged programs are to be supported, it
makes sense to provide some mechanism for their convenient use and to
take some care that the need to distribute such programs does not
increase our operator's vulnerability to purposeful malice [8].

We are also generally concerned with the ability to authenticate
authors to interlocutors [9] though we take care not to conflate
authentication with authorization [10].

Questions
---------

Conceptually speaking, there are several sorts of sensitive data around
which we might consider creating locks, for example:

   * UI-relevant identifiers like 'author' or 'package-name'
   * endowed permissions
   * private data of various sorts e.g. in the datastore or rainbow spool

How, precisely, should this be done? 

Concerning credentials and environments:

   * What credentials should be considered sufficient to open each of
     these potential locks? 
   
       * By what interaction might the operator forcefully open a lock?

   * Must be we able to guarantee access to sufficient credentials to
     laptop distributors and support organizations like OLPC?
   
       * If so, how might we do so? By key delegation? By escrow?

   * What conditions may be made necessary for the ability to generate
     credentials?

   * What conditions must taken to be sufficient for the ability to
     generate credentials?

   * What conditions may be made necessary for the ability to verify
     messages with given credentials?

   * What conditions must taken to be sufficient for the ability to
     verify messages with given credentials?

   * Is it good to try to aggregate credentials in some form of
     registry?

Concerning protocols:
   
   * Does the authorization+endowment protocol need to be versioned?
   
       * If so, how should we expect to respond to messages from older
         versions?

   * Does the authorization+endowment protocol implementation need to be
     exposed as a public API?
   
   * How should we respond to invalid protocol messages?
  
   * If a Debian-scale compromise occurred, what responses might be
     available?

   * Should software packages be able to 'pin' themselves (preventing
     the installation of other versions of the package until
     forcefully overridden, perhaps by preparatory uninstallation)?

   * Should privilege endowments be automatically transferred newly
     encountered versions of an existing thing?

       * If this could be done in multiple ways, which way should be
         chosen?
       
       * How about other sensitive things like 'instance-specific data'?

   * Are there existing models for this sort of thing (e.g. [11]) which
     can be reused in some way?

Concerning use via Sugar on XOs:

   * where might XO-user-owned credentials live?

   * how might the user request their use?

   * what would prevent other programs from using them without
     authorization?

   * how might authorization be granted to programs (e.g. Pippy) to which
     the user wants to offer some use of the credentials?

References
----------

[1]: Bitfrost's directive on activity signing.
-->  http://tinyurl.com/4zb6ux#l450

[2]: Ivan's writings on activity update.
-->  http://tinyurl.com/3r4f2z

[3]: #5657 - Loophole'd activities.
-->  http://dev.laptop.org/ticket/5657

[4]: Activity updater design document.
-->  http://wiki.laptop.org/go/Software_update

[5]: First commentary on bundles and bundle versioning.
-->  http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1

[6]: Second commentary on bundles and bundle versioning.
-->  http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2

[7]: Foreword of the Rainbow design document.
-->  http://tinyurl.com/4hlsn8#l40

[8]: Bitfrost's discussion of purposeful vs. circumstantial malice.
-->  http://tinyurl.com/4zb6ux#l379

[9]: Definition of P_IDENT.
-->  http://tinyurl.com/4zb6ux#l838

[10]: "Knowing my interlocutor doesn't mean I trust their code."
-->   http://tinyurl.com/4zb6ux#l497

[11]: Security and Permissions in Android
-->   http://code.google.com/android/devel/security.html