[OLPC Security] "Correlating bitfrost and threats"

[MBurns]

On 7/30/07, Jameson Chema Quinn <jquinn at cs.oberlin.edu> wrote:
>
> Many of you are probably aware of the document on the wiki, "Correlating
> Bitfrost and Threats", attributed to Marc Stiegler. http://wiki.laptop.org/go/Correlating_Bitfrost_and_Threats
> . Still, browsing the archive for this mailing list, I do not see that
> this document has been discussed.


I hadn't seen it (thank you for pointing it out). Went ahead and read it and
will add my feedback into the appropriate wiki section. Brief comments
below. I encourage discussion on the list, though. This is where most people
watch for such talk, and is a much more natural place to have a discussion.


>    - The installation of applications under Bitfrost should be tweaked
>    so that, in addition to asking the application for a list of requested
>    endowments, the user is asked what kind of application is being installed
>    ("category-based installation"). The installation endowment becomes the
>    intersection of those endowments requested, and those endowments appropriate
>    for the application type.
>
>
Good on paper but I'm not convinced this could be shown to be useful in
practice. The vector this is explained through is email attachments. That a
malicious attachment (shock!) could be sent via email, somehow executed and
rub with the email activity's Bitfrost permissions. To avoid this, instead
of using vague (and contradictory) labeling systems, we will simply not let
attachments be openly executed, a lesson we learned a decade ago. When they
are executed, it is either (1) exploiting some Mail or Web activity(local or
webmail, respectively), and are thus confined to the rate limiting,
datastore limiting and containerization that are inherint to Bitfrost for
such activities or (2) it is--less likely, given the scenario--seen as a new
activity/application and the first-run installation sequence would be used.
Again, limited to the containers, datastore limitation and token bucketing
that limits the scope of any executable would have.


>    - A computer-based training system that makes olpc owners resistant
>    to nigerian hoaxes should be explicitly included in the security
>    specification.
>
> Training is beyond the scope of Bitfrost itself, of course. Training
materials that are properly i18n'able and such I'm sure would be useful. A
global help system for the XOs is being planned, and this is likely the
proper place to explore the idea.


>    - The Bitfrost mechanism for updating firmware should be given a
>    detailed end-to-end security review to ensure attackers cannot breach the
>    system and render olpc computers unrecoverable.
>
>
Absolutely. This is covered in Bitfrost @ P_BIOS_CORE


>    - Resources for these additional development efforts can be acquired
>    by postponing development of the centralized "anti-theft" user
>    identification system and the centralized backup system until a later
>    release.
>
>
No, they can't. Anti-theft is a highly, highly requested feature from  our
launch countries (from what I understand). Also, backup systems are
critically important for a first-launch system. The likelihood of bugs is
exponentially higher the newer the code, as is true of any software project,
so being able to cope with such potential failures is an absolute must.


>    - If olpc is unable to abandon these centralized systems,
>    decentralized architectures are proposed that achieve the same goals while
>    reducing single point of failure risk and privacy risk.
>
> Currently, yes, the P_Theft systems phones home (the mechanism is
optional, not required) to a centralized system. Making it more distributed
is perfectly acceptable, and I am sure we would appreciate discussion in
this direction. Something akin to the backup system (see next graph) might
be reasonable;. Thoughts?

The decentralized goals of data backup (if this is what you were thinking as
part of 4a) is also addressed. Data is has a trickle up ability of the
datastore of the XO, an SD card(?), the school server, potentially regional
server(s), potentially country server(s) and some Global Servers In The Sky
system. This is as distributed as can be. All data, again, is encrypted, so
no peeping toms can look what their children are doing. Further suggestions
are always welcome.

Cheers!

-- 
Michael Burns * Intern
One Laptop Per Child
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20070730/fbfe4f2a/attachment.htm