On Fri, Aug 1, 2008 at 4:01 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 1, 2008 at 5:01 PM, Jameson Chema Quinn > <[EMAIL PROTECTED]> wrote: > > 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
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
