User:Mstone/Rainflow: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
m (→Background) |
||
| (23 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
== Introduction == |
|||
Carrying on the tradition of naming [[Rainbow|software]] via puns, I'll lay down some thoughts on how to answer the question: |
|||
Software which cannot function in isolation exposes users to contingent hazards because users cannot perfectly distinguish benign from malicious software. For example: |
|||
: ''When should our software automatically do risky thing X?'' |
|||
: ''Suppose that we have mechanically acquired a program that purports to be Terminal-31. Suppose further that the program tells us that it is intended to be run de-isolated. Should we discard it, install it, or dialogue with the user?'' |
|||
In order to make this decision, the users' factotum needs two things: ''policy'' and ''evidence''. |
|||
: By ''policy'', I mean a labeling of a ''universe'' of actions (e.g. "discard", "install", or "dialogue") with some description of the circumstances under which the user might want the factotum to perform the labeled action. |
|||
: By ''evidence'', I mean roughly the information that decision-makers consume in order to reach good decisions. |
|||
Now for the hard parts: |
|||
* ''where do policies and evidence come from?'' |
|||
* ''what are they like?'' |
|||
== Rainflow == |
|||
I'm going to assert, just to get on with things, that policy is just a pair of switches: |
|||
* a risk switch with two positions -- "I've got nothing to protect" and "I've got something to protect" and |
|||
* an interaction switch with two positions -- "I never want to hear from you" and "I always want to hear from you". |
|||
I'm also happy to declare that the OS distributor needs to choose an initial policy by whatever means seem best to them. |
|||
We are therefore left to consider the remaining challenge: evidence. |
|||
=== Witness Activity === |
|||
# People who want to create evidence about a ''subject'' should participate in a shared ''Witness activity''. |
|||
# Within that activity, they should generate a ''position'' about their subject. |
|||
# All available witnesses should collectively certify an ''affidavit'' (i.e. the position, its consensus set, and the set of remaining witnesses) with a multisignature. |
|||
== Exploratory Implementation == |
|||
For the purposes of exploration, and with no care for proper use of cryptography, we might take positions to be "the evil bit", e.g.: |
|||
My position on Terminal-31: |
|||
hash("ABCD0123"). |
|||
name("Terminal"). |
|||
version("31"). |
|||
good. |
|||
My consensus set: |
|||
27A9023A3642A3638EF67511B6D5DCC8E1D5034E Michael Stone |
|||
... |
|||
My witness set: |
|||
27A9023A3642A3638EF67511B6D5DCC8E1D5034E Michael Stone |
|||
... |
|||
== Background == |
== Background == |
||
| Line 11: | Line 61: | ||
: [[User:Mstone/Commentaries/Bundles_1|activity semantics conversation]] |
: [[User:Mstone/Commentaries/Bundles_1|activity semantics conversation]] |
||
: [http://lists.laptop.org/pipermail/devel/2008-March/011553.html runtime build customization thread] and <trac>6432</trac> |
: [http://lists.laptop.org/pipermail/devel/2008-March/011553.html runtime build customization thread] and <trac>6432</trac> |
||
: [http://lists.laptop.org/pipermail/security/2007-December/000341.html user-created activities and updates thread] |
: [http://lists.laptop.org/pipermail/security/2007-December/000341.html bemasc's user-created activities and updates thread] |
||
: [http://lists.laptop.org/pipermail/devel/2008-March/012131.html horizontal distribution thread] |
: [http://lists.laptop.org/pipermail/devel/2008-March/012131.html horizontal distribution thread] |
||
: [[Bundles and updates|homunq's ideas on bundles and updates]] |
: [[Bundles and updates|homunq's ideas on bundles and updates]] |
||
| Line 17: | Line 67: | ||
Most likely, others have shared analogous concerns in their environments: |
Most likely, others have shared analogous concerns in their environments: |
||
: [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html keysigning party howto] |
|||
: [http://packages.debian.org/lenny/debian-keyring Debian keyring] |
|||
: [http://en.wikipedia.org/wiki/CAcert.org CAcert.org] |
|||
: [http://www.cs.purdue.edu/homes/ninghui/ Ninghui Li] |
|||
: ''citations needed'' |
: ''citations needed'' |
||
This proposal offers some new details for adventurous devil-spotters to peruse. |
|||
Latest revision as of 17:32, 5 July 2009
Introduction
Software which cannot function in isolation exposes users to contingent hazards because users cannot perfectly distinguish benign from malicious software. For example:
- Suppose that we have mechanically acquired a program that purports to be Terminal-31. Suppose further that the program tells us that it is intended to be run de-isolated. Should we discard it, install it, or dialogue with the user?
In order to make this decision, the users' factotum needs two things: policy and evidence.
- By policy, I mean a labeling of a universe of actions (e.g. "discard", "install", or "dialogue") with some description of the circumstances under which the user might want the factotum to perform the labeled action.
- By evidence, I mean roughly the information that decision-makers consume in order to reach good decisions.
Now for the hard parts:
- where do policies and evidence come from?
- what are they like?
Rainflow
I'm going to assert, just to get on with things, that policy is just a pair of switches:
- a risk switch with two positions -- "I've got nothing to protect" and "I've got something to protect" and
- an interaction switch with two positions -- "I never want to hear from you" and "I always want to hear from you".
I'm also happy to declare that the OS distributor needs to choose an initial policy by whatever means seem best to them.
We are therefore left to consider the remaining challenge: evidence.
Witness Activity
- People who want to create evidence about a subject should participate in a shared Witness activity.
- Within that activity, they should generate a position about their subject.
- All available witnesses should collectively certify an affidavit (i.e. the position, its consensus set, and the set of remaining witnesses) with a multisignature.
Exploratory Implementation
For the purposes of exploration, and with no care for proper use of cryptography, we might take positions to be "the evil bit", e.g.:
My position on Terminal-31:
hash("ABCD0123").
name("Terminal").
version("31").
good.
My consensus set:
27A9023A3642A3638EF67511B6D5DCC8E1D5034E Michael Stone ...
My witness set:
27A9023A3642A3638EF67511B6D5DCC8E1D5034E Michael Stone ...
Background
People in the OLPC community have been concerned with this question (and with variants and related questions) for some time:
- <trac>5657</trac>, on spoofing-resistant update algorithms for de-isolated activities
- questions on activity signing and update thread
- activity semantics conversation
- runtime build customization thread and <trac>6432</trac>
- bemasc's user-created activities and updates thread
- horizontal distribution thread
- homunq's ideas on bundles and updates
Most likely, others have shared analogous concerns in their environments:
- keysigning party howto
- Debian keyring
- CAcert.org
- Ninghui Li
- citations needed