preliminary [PATCH] and discussion for #5657: activity isolation for all activities in ~/Activities

[Jameson "Chema" Quinn]

Problem: anything named "Journal", "Terminal", "Log", or "Analyze" is not
isolated. This is the biggest security hole we have right now: it is a
trivial way for any activity to get root access.

Idea: as a short-term hack (until we have good cryptographic signatures for
activities), only turn off isolation if an activity is in
.../share/sugar/activities. Installation here is only possible for root (or
at build time).

Implementation:
This makes sense to implement in activitybundle.py, respecting a line in
activity.info like:
bitfrost_requests = P_ROOT, P_OTHER_UNIMPLEMENTED_THING, ...
That means that the data then passes up the chain: to bundleregistry, to
activityregistryservice, to sugar.activity.registry, and then to
activityfactory. Passing it up the chain meant fixing the call signatures
all the way along, and doing some refactoring along the way.

Status:
Works, not well tested (I will test more before submitting it definitively.
Also I'll have to include the patch to Journal's activity.info. Patches to
the other activities and packaging concerns will wait for round 3.) Marcopg
or others, feel free to start the review on the included patches; there are
enough bigger design decisions evident that we can get a jump on review even
before I do the solid testing on Monday.

Consequences:
- Changing the four activities named above to be installed in
share/sugar/activities. To remove them, a country would need to use a
customization key.
- If the activities above are in a country's build, they cannot be
uninstalled by user. If they are upgraded by user, they lose their
unisolated powers; if the upgrade is removed, they regain them. (Not tested)

Related issues:
- The use of version numbers to distinguish two versions of a single
activity is improved by this patch, but is still inconsistent. Erratic
behaviour is expected when two versions of the same activity are present,
although in normal use (all installation through the journal) this would
never happen as the older versions would be uninstalled automatically.
- Of course, the long-term solution is activity signatures.
- It will still be possible for a web link to claim to be activity X, but to
actually replace Browse (or other) with a trojanned version. (I know, this
is only weakly related, but it came up while I was discussing this patch
with Eben, so I mention it here.) I tracced this: #7761
 <http://dev.laptop.org/ticket/7761>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080801/d3286e6f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-bug-5657-gets-security-requests-from-activitybundl.patch
Type: text/x-diff
Size: 14130 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080801/d3286e6f/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-bug-5657-bitfrost-requests-in-bundle-handled-in-r.patch
Type: text/x-diff
Size: 10532 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080801/d3286e6f/attachment-0001.patch>