[OLPC Security] 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/security/attachments/20080801/d3286e6f/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-bug-5657-gets-security-requests-from-activitybundl.patch
Type: text/x-diff
Size: 14129 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/security/attachments/20080801/d3286e6f/attachment-0002.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: 10531 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/security/attachments/20080801/d3286e6f/attachment-0003.patch

[C. Scott Ananian]

On Fri, Aug 1, 2008 at 5:01 PM, Jameson Chema Quinn

Post by Jameson &quot;Chema&quot; 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.

Another possible short-term hack is to simple disable
activitybundle.install() and activitybundle.upgrade() for bundes with
bundle_ids matching those of Journal, Terminal, Log, or Analyze. This
allows these activities to be installed in /home/olpc/Activites with a
customization key, as usual, but prevents malicious attackers from
using a web link or the activity updater to replace the
originally-installed versions.

This has the benefit of (a) not requiring us to revisit the
"activities in /home" war, and (b) allowing us to upgrade the versions
of these trusted activities in /home in (say) 9.1, using the "proper"
mechanism.
--scott

[Jameson &quot;Chema&quot; Quinn]

Post by C. Scott Ananian
On Fri, Aug 1, 2008 at 5:01 PM, Jameson Chema Quinn

Post by Jameson &quot;Chema&quot; 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.

Another possible short-term hack is to simple disable
activitybundle.install() and activitybundle.upgrade() for bundes with
bundle_ids matching those of Journal, Terminal, Log, or Analyze. This
allows these activities to be installed in /home/olpc/Activites with a
customization key, as usual, but prevents malicious attackers from
using a web link or the activity updater to replace the
originally-installed versions.
This has the benefit of (a) not requiring us to revisit the
"activities in /home" war, and (b) allowing us to upgrade the versions
of these trusted activities in /home in (say) 9.1, using the "proper"
mechanism.
--scott

I like this idea. Of course, it means that can install using "cp -r",
including installing a trojan activity which does not *look* like Terminal.

... My patch has activities requesting P_ROOT in activity.info. Could we
simply refuse to do a normal install for such activities? We could even keep
a list of them, and not respect what's not on the list, and only update the
list on a keyed install. This is not as secure as signatures, because a
sneaky attack could still modify the contents of an installed activity, but
it is getting pretty close.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080801/17ee8c6e/attachment.htm