Michael Stone
2008-10-11 07:13:13 UTC
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
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