Log in

No account? Create an account
entries friends calendar profile adric.net Previous Previous Next Next
Rainbow interactions with Activity processes, rate limiting specs - nil.enroll(aetheric_username, quantum_class_id)
yljatlhQo'! QIch lo'laltbebej!
Rainbow interactions with Activity processes, rate limiting specs

Thanks for correcting me and some clarification, and many thanks for bringing us back on topic. :)
And the rest is inline...

On Nov 30, 2007, at 1:24 AM, Michael Stone wrote:

Specifically, it's fairly clear from the needs of software like Browse
and Etoys that 'activity instances' are not in one-to-one correspondence
with processes or even process-groups. This means that you may not know
which uid to kill off in order to close a given activity instance and
that one uid may be hosting several unrelated activities.

Hmm, I'm not entirely sure I follow you here... If you could sketch out an
activity instance, please, so that I (we) see the bigger picture than the processes?
Or is there wiki on that already that I missed?

All of these kinds of communication create unknown levels of risk of
cross-instance contamination. The ones involving the datastore may
persist across reboots. Finally, each suggests the possibility of
running privilege-escalation attacks against system and session
components that I am hard-pressed to mitigate on any reasonable

Okay, now that I understand. And we have a lot of executable code/content
that we want them to share cross-Activity and even across the mesh. This is
going to be a vector.

To come to Marcus' defense here, he's one of the people who has
contributed most directly to implementing Bitfrost by code review, patch
submission, and regular testing to ensure that the code continues to run
under emulation.


Depends on whether you're able to specify workable limits and on the
rate at which exploits are developed for the activities that are endowed
with network access. (or for the underlying system as a whole).

And this is something still under development and scrutiny. We (I) should probably start testing this (on closed networks, at first) to see how bad things are in the current builds. I know that this stuff has limited implementation so far ? eg /etc/rainbow ?

Here's a potential weakness that concerns me: how rapidly can we
actually deploy a security patch to, say, avahi or the presence service?

This is a major concern, and one that may be out of spec because of the distribution methods. To my understanding once the XOs go out, laptop.org may never hear from them again, in many non-edge cases. Of course the sponsoring government and classrooms will be encouraged to distribute patches to all of their XOs, but ... *gulp*

When if ever are y'all on IRC? :)

Adric Net

Woot! Someone with a clue has called me down and gotten discussion moving forward again! Success? Later, 0830: Although I do seem to have derailed some of the noise back onto the topic (yay), I may have accidentally pissed off some of the real hackers (f---) at the same time, so I apologized in this post, and more directly in person to another in email.

Current Location: bedroom (now with light)

Leave a comment