<div dir="ltr">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.<br>
<br>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).<br>
<br>Implementation:<br>This makes sense to implement in activitybundle.py, respecting a line in <a href="http://activity.info">activity.info</a> like:<br>bitfrost_requests = P_ROOT, P_OTHER_UNIMPLEMENTED_THING, ...<br>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.<br>
<br>Status:<br>Works, not well tested (I will test more before submitting it definitively. Also I'll have to include the patch to Journal's <a href="http://activity.info">activity.info</a>. 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.<br>
<br>Consequences:<br>- 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.<br>- 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)<br>
<br>Related issues:<br>- 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.<br>
- Of course, the long-term solution is activity signatures.<br>- 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: <a href="http://dev.laptop.org/ticket/7761">#7761<br>
</a></div>