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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel